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-  A  prototype  "presentation  system  base"  is  described.  It  offers  mechanisms, 
tools,  and  ready-made  parts  for  building  user  Interfaces.  A  general  user  inter¬ 
face  model  underlies  the  base,  organized  around  the  concept  of  a  "presentation": 
a  visible  text  or  graphic  form  conveying  information.  The  base  and  model  em¬ 
phasize  domain  independence  and  style  independence,  to  apply  to  the  widest 
possible  range  of  interfaces.  "^he  "primitive  presentation  system  model" 
treats  the  interface  as  a  system  of  processes  maintaining  a  semantic  relation 
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, between  an  "application  data  base'"  and  a  "presentation  data  base",  the  symbolic 
screen  description  containing  presentations.  A  "presenter"  continually  updates 
the  the  presentation  data  base  from  the  application  data  base.  The  user  manipulates 
presentations  with  a  "presentation  editor".  A  "recognizer"  translates  the  user's 
presentation  manipulation  into  application  data  base  commands.  The  primitive 
presentation  system  can  be  extended  to  model  more  complex  systems  by  attaching 
additional  presentation  systems.  In  order  to  Illustrate  the  model's  generality 
and  descriptive  capabilities,  extended  model  structures  for  several  existing 
user  interfaces  are  discussed. 

The  base  provides  support  for  building  the  application  and  presentation  data 
bases,  linked  together  into  a  single,  uniform  network,  graphics  to  continuously 
display  it,  and  editing  functions.  A  variety  of  tools  and  mechanisms  help 
create  and  control  presenters  and  recognizers.  To  demonstrate  the  base's  utility, 
three  interfaces  to  an  operating  system  were  constructed,  embodying  different 
styles:  icon,  menu,  and  graphical  annotation.. 
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Abstract 

A  prototype  presentation  system  base  is  described.  It  olTers  mechanisms,  tcnals,  and  ready¬ 
made  parts  for  building  user  interfaces.  A  general  user  interface  nK)del  underlies  the  b:ise, 
organized  around  the  concept  of  a  presentation:  a  visible  text  or  giaphic  form  conveying 
information.  The  base  and  model  emphasize  domain  independence  and  style 
independence,  to  apply  to  the  widest  possible  range  of  interfaces. 

The  primitive  presentation  system  model  treats  the  interface  tis  a  system  of  processes 
maintiiining  a  semantic  relation  between  an  application  data  base  and  a  presentation  data 
base,  the  symbolic  screen  description  containing  presentations.  A  presenter  continually 
updates  the  prcsenuition  data  base  from  the  application  data  base.  I'he  user  manipulates 
presentations  with  a  presentation  editor.  A  recognizer  translates  the  user's  prcscnUition 
manipulation  into  application  d:ita  base  commands.  Ihe  primitive  presentation  system  can 
be  extended  to  model  more  complex  systems  by  attaching  additional  prcsenUition  systems. 
In  order  to  illustrate  the  modcl'.s  generality  and  descriptive  capabilities,  extended  model 
structures  for  several  existing  user  inlcrfiiccs  are  discussed. 

The  b  asc  provides  support  for  building  the  application  and  presentation  data  bases, 
linked  together  into  a  single,  uniform  network,  including  descriptions  of  classes  of  objects  as 
well  as  the  objects  themselves.  Ihe  btese  provides  an  initial  presentation  data  ba.se  network, 
graphics  to  continuously  display  it.  and  editing  functions.  A  variety  of  tools  and 
mechanisms  help  create  and  control  presenters  and  recognizers.  To  demonstrate  the  base’s 
utility,  three  interfaces  to  an  operating  system  were  constructed,  embodying  different  styles; 
icon.  menu,  and  graphical  annotation. 
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Chapter  One 

Introduction  and  Overview 


Ikiilding  gixJtl  user  iiiicrfaccs  is  a  slow  ;ind  dilTicult  process.  Good  user  interfaces  are 
generally  large,  complex,  and  hard  to  understand,  atid  those  characteristics  tend  to  be 
exacerbated  when  the  interface  is  modified.  All  too  often,  interfaces  arc  built  that  lack 
ficxibility  in  their  use.  lack  some  functionality,  or  lack  uniformity  with  interfaces  to  dilTcrent 
applications. 

The  primary  result  of  this  research  is  the  development  of  a  prototype  presentation  system 
base,  called  PSBa.se.  PSBase  contains  tools,  mechanisms,  and  ready-made  parts  for  the 
construction  of  user  interfaces.  Independence  of  particular  interface  styles  and  application 
domains  is  cmpliasi/cd,  in  order  to  ma.ximize  the  generality  and  utility  of  the  bttsc.  PSBase 
also  provides  a  conceptual  framework  for  user  interfaces.  Underlying  the  base  is  a  general 
model  of  user  interfaces,  called  the  presentation  system  model.  The  report  cl.iims  that,  with  a 
presentation  ba.se,  interface  construction  is  easier  and  quicker,  and  the  results  arc  better. 

To  demonstrate  the  utility  of  PSBase,  a  user  interface  was  constructed  on  top  of  it,  and 
three  different  styles  were  implemented  for  this  interface.  A  presentation  system  base 
slnnild  be  independent  of  any  particular  application  domain  or  any  particular  interface 
style.  It  should  support  the  construction  of  (and  experimentation  with)  many  different 
kinds  of  applications  and  styles. 

For  example,  consider  die  following  spectrum  of  styles.  At  one  end  is  direct  manipulation 
(Shneiderman  83];  the  object  of  interest  is  continually  displayed,  and  the  user's  actions 
appear  to  be  manipulating  the  object  with  no  intervening  command  language.  An 
alternative  style  is  preparing  a  desired  future  version.  (  I  his  style  looks  the  same  ;is  direct 
manipulation,  but  the  object  of  interest  is  not  continually  changing  -  the  specification  of  the 
future  version  is.).  Another  style  is  annotating  the  current  view  with  commands  for  how  to 


ehaiige  ihc  object.  At  tlic  other  extreme  from  direct  manipulation  is  a  separate  command 
language  for  describing  the  manipulation.  r..\amples  of  these  alternative  styles  can  be  seen 
when  readers  request  changes  in  a  draft  paper:  sometimes  the  original  file  is  edited, 
sometimes  a  new  file  is  created,  sometimes  the  (paper)  draft  is  annotated,  and  sometimes  the 
clianges  are  discussed  separately. 

Another  result  of  this  research  is  the  presentation  system  model  itself.  I  his  is  a  general 
model  of  user  interfaces,  and  it  is  the  foundation  of  PSliase.  Even  by  itself,  however,  it  has 
benefits.  It  aiils  the  understanding  of  user  interfaces  in  general  by  providing  a  unifying  set 
of  concepts  for  thinking  about  user  interfaces.  I'hcre  are  two  ways  that  it  helps  someone 
building  a  u.ser  interface  in  the  absence  of  a  presentation  system  base.  It  serves  as  a  checklist 
of  the  possible  kinds  of  functionality  in  a  user  interface,  fhe  structure  of  the  model  serves 
as  an  architectural  framework  for  the  interface. 

The  model  may  also  be  of  aid  to  people  studying  interface  styles  in  general.  One  problem 
in  such  a  study  is  the  large  number  and  diversity  of  possible  styles.  The  model  defines 
various  classes  of  general  parameters  for  interfaces.  One  can  define  styles  tis  patterns  of 
these  parameter  specifications. 

[  he  following  five  sections  provide  an  overview  of  the  five  major  chapters  in  this  report. 
Tlicsc  chapters  divide  into  two  groups.  The  first  group,  comprising  chapteis  two.  Uirce.  and 
four,  discusses  the  presentation  system  model  that  underlies  the  presentation  system  bttse. 
The  second  group,  comprising  chapters  five  and  six,  discusses  the  presentation  system  base 
and  its  application. 

1.1  The  Primiliyc  Presentation  System  Model 

This  section  introduces  the  primitive  presentation  system  (I’PS)  model  of  user  interfaces, 
which  is  discussed  further  in  chapter  two.  Two  simple  models  of  a  data  base  interface  will 
first  be  introduced.  T  hey  will  be  used  to  focus  attention  on  certain  aspects  and  to  motivate 
the  development  of  the  full  PPS  model.  The  first  model  Rkuscs  on  the  data  b;ise. 
considering  a  rudimentary  interface  to  it.  T  he  second  model,  the  representation  shift  modei 


focuses  oil  ihe  user's  need  for  a  more  useful  and  coherenl  represontalion  of  ihc  daia  base 
information  and  commands,  flic  representation  shift  model  is  also  useful  in  itself  as  it  is  a 
special  ease  of  the  full  PPS  model  and  applies  to  some  common  interface  .stylc.s.  Hie  PPS 
model  extends  the  representation  shift  model  to  allow  more  llexibility  in  the  relationship 
between  the  screen  and  the  data  base. 

A  Rudimentary  LI.scr  Interface.  Figure  1-1  shows  the  basic  interface  to  an  application  data 
base  and  a  rudimentary  user  interface  constructed  from  it.  The  data  base  has  three  external 
inputs  and  outputs.  Commands  change  the  slate  of  the  data  base  (adding,  changing,  or 
deleting  information).  Queries  allow  the  state  of  the  data  base  to  be  examined,  producing 
the  relevant  information  at  the  observables  output 

These  inputs  and  outputs  are  not  directly  usable  by  a  person  -  they  arc  in  a  format 
designed  for  use  by  programs.  (The  user  is  not  the  only  one  using  data  bases,  after  all.)  In 
order  to  provide  even  a  rudimentai7  user  interface,  some  simple  kind  of  transducers  must  be 
placed  on  each  input  and  output  line. 

The  transducer  on  the  command  input,  for  example,  might  convert  a  text  version  of  a 
command  to  the  binary  form  required  by  the  data  base,  flic  transducers  do  not  provide  a 
different  overall  model  of  data  base  use  --  the  user  still  must  use  the  commands  and  queries 
provided  by  the  data  base.  The  language  used  to  express  them  has  been  changed  slightly  so 
that  it  is  printable  and  mnemonic,  much  tlte  same  kind  of  translation  that  a  simple 
assembler  performs. 

The  rudimentary  interface  is  usable,  but  suffers  from  two  basic  problems  from  the  user’s 
point  of  view.  First,  the  user  must  express  the  data  base  modification  in  terms  of  tlie  data 
base  aimmands  available.  Second,  the  results  of  such  modification,  as  well  as  any  viewing 
desired,  must  be  explicitly  requested  via  queries. 

Representation  Shift.  Figure  1-2  shows  an  expanded  user  interface.  Here,  two  data  bases 
arc  involved,  the  application  data  base  as  before  and  a  new  one,  called  a  presentation  of  the 
data  b;usc,  introduced  to  allow  the  user  more  direct  modification  and  viewing.  ITie 


prcscnUilion  ilata  base  conlains  Ihc  Siimo  inrornialion  as  the  application  data  base,  l)iil  it  is 
rcprcseiued  in  a  way  that  is  directly  viewable,  i.e..  in  terms  of  text  and  graphic  (brms.  It  is 
continuously  displayed  (on  the  user's  terminal),  so  that  the  user  docs  not  have  to  explicitly 
request  information  to  be  viewed. 

Ihc  presentation  --  or.  kxjscly  speaking,  the  screen  --  can  be  directly  edited  by  the  user, 
by  means  of  the  presentation  editor.  The  editor  allows  the  user  to  manipulate  the  forms  on 
the  screen,  creating  new  forms  or  changing  or  deleting  existing  ones.  Conceptually,  it 
combines  capabilities  of  a  text  editor  with  those  of  a  graphics  (diagram)  editor.  As  these 
changes  arc  made,  their  results  arc  immediately  visible. 

In  addition,  the  commands  for  presentation  editing  are  chosen  to  be  convenient  for  the 
user.  For  example,  they  might  include  a  base  of  general  text-editing  and  graphics-editing 
commands,  so  that  the  user  does  not  have  to  learn  a  special  language  for  each  particular 
application  data  base. 

The  presenter  creates  the  presentation  data  base  from  the  application  data  base.  At 
appropriate  times  as  the  user  edits  the  presentations,  the  recognizer  creates  a  new  version  of 
the  application  data  base  from  the  presentation  data  base.  In  the  representation  shift  model 
the  presentation  contains  all  anti  only  the  information  contained  in  the  application  data 
base.  The  presenter  uses  a  single  application  data  base  query  (labeled  t^et-db  in  the  figure) 
to  get  a  representation  of  the  entire  application  data  base,  converts  the  representation,  and 
then  uses  a  single  presentation  data  ba.se  command  (labeled  load-db)  to  load  the  entire 
presentation  data  base.  Similarly,  the  recognizer  gets  the  entire  presentation  contents, 
converts  it,  and  loads  the  entire  application  data  base. 

In  the  representation  shift  model,  the  presenter  relation  must  be  invertible,  since  the 
recognizer  must  be  able  to  specify  the  entire  application  data  base  from  the  presentation 
data  base.  In  general  the  presenter  relation  is  a  subset  of  the  recognizer  relation,  or  in  other 
words,  the  recognizer  will  recognize  several  different  variants  of  the  stime  presentation, 
allowing  the  user  more  latitude  For  example,  the  recognizer  might  allow  the  user  to  create 
any  of  "12",  "12.0",  "12.000",  etc.,  whereas  the  presenter  might  always  choose  "12.0". 


The  rcproscntalion  shift  model  is  a  direct  manipulation  interface  [Shneiderman  83],  I  hc 
screen  continuously  displays  the  data  base.  Whenever  the  data  base  changes,  the  screen  is 
updated.  Similarly,  the  user  manipulates  the  data  base  by  manipulating  the  forms  on  the 
screen,  and  the  data  base  istTnUinually  updated  from  this. 

rhe  major  restriction  of  the  representation  shift  model  is  that  the  e/;//re  application  data 
base  be  viewed  (and  in  an  invertible  presentation).  This  can  lead  to  inefficiency.  It  can  also 
lead  to  the  inconvenience  of  visual  clutter  --  tlie  user  cannot  view  just  a  relevant  subset  of  a 
complex  data  base.  Ilie  ability  to  control  the  selection  of  information  to  be  viewed  and  the 
way  it  is  to  be  viewed  can  be  crucial  to  the  successful  use  of  the  data  base. 

The  Full  PPS  Model.  Tlie  full  PPS  model,  shown  in  figure  1-3.  relaxes  the  restriction  that 
die  entire  application  data  base  must  be  viewed.  The  presentation,  i.e.,  die  visual  data  base, 
may  convey  only  a  .small  part  of  the  information  in  the  application  data  base.  The  screen 
thus  can  no  longer  be  recognized  in  a  simple  manner  as  specifying  all  the  information  in  the 
application  data  biisc.  This  necessitates  a  generalization  in  the  recognizer  from  diat  in  the 
representation  shift  model:  the  recognizer  translates  editing  actions  into  data  base 
commands,  rather  than  translating  editing  results  into  data  b;isc  data.  (The  term  editing 
actions  includes  both  the  editing  command  and  the  editing  result  Ihercforc,  the  PPS 
recognizer  includes,  as  a  special  case,  the  possibility  of  just  having  to  examine  the  editing 
result) 

The  presenter  is  responsible  for  making  the  screen  continually  show  the  relevant  part  of 
the  data  base.  It  creates  the  initial  display  and  updates  the  display  when  the  data  base 
changes.  The  presenter  collects  the  relevant  information  from  the  application  data  base, 
ainvcrls  that  information  to  text  and/or  graphics,  and  organizes  the  layout  of  this  visual 
information  on  the  screen. 

I'he  recognizer  causes  the  data  base  to  change  to  reflect  the  user's  editing  of  the 
presentation.  Specifically,  in  addition  to  affecting  the  screen,  the  user's  editing  operations 
are  recognized  ;is  -  i.e.,  translated  into  -  operations  on  the  data  base.  Thus,  the  PPS  model 
is  also  a  direct  manipulation  interface:  the  data  base  is  continually  presented  on  the  screen. 


Figure  1-3:  The  Primiiive  Presentation  System  (PPS)  Model 


with  screen  rollovving  cl;ila  base  changes  (by  presenter  action)  and  data  base  following  screen 
changes  (by  recognizer  action). 

1.2  Coivstructing  Larger  Prcscnlation  Sy.slcm  Models 

The  primitive  presentation  system  model  can  be  extended  to  model  more  complex 
presentation  systems  as  discussed  in  chapter  three.  I  hc  basic  technique  for  extending  the 
presentation  system  model  is  to  attach  an.  additional  presentation  system  to  it.  either 
replacing  or  augmenting  some  part  of  it.  The  resulting  presentation  system  may  thus 
contain  several  smaller  presentation  systems.  Ihe  extensions  discussed  in  this  section  are 
suggested  by  examining  the  major  limitations  of  the  PPS  model. 

Adding  a  Planned  l).ita  llase.  In  the  PPS  model  changes  to  the  data  base  are  immediate. 
To  avoid  this,  a  second  application  data  bttse  can  be  added  to  a  presenLation  system:  a 
future  (i.e.,  planned)  version  of  the  original  data  base.  The  user  can  edit  the  planned 
version's  presentation,  separate  from  the  presentation  of  the  current  state  of  the  data  base. 
When  the  planned  version  looks  acceptable,  the  user  gives  a  do  it  command  that  causes  the 
actual  data  bttse  to  be  updated. 

Adding  a  Data  Base  of  Commands.  In  the  PPS  model  the  user  cannot  see  a  description  of 
the  changes  or  the  commands  to  clTect  them  presented  explicitly.  (Only  the  data  base  that 
results  from  these  commands  is  seen.)  Using  a  technique  similar  to  the  previous  one  of 
adding  a  planned  version  of  the  data  base,  a  data  base  of  commands  can  be  added.  In  this 
extension,  the  planned  changes  are  represented  in  the  new  data  base  explicitly,  and  can  be 
presented  in  a  style  different  from  the  style  for  the  application  data  base. 

Adding  Interfaces  to  IM*S  Components.  In  the  PPS  model  the  editor,  presenter,  and 
recognizer  are  not  presented;  the  user  only  has  an  interface  of  primitive  signals  to  them 
(e.g.,  keystrokes  or  a  pointing  device).  To  circumvent  this  limitation,  presentation  system 
interfaces  to  these  components  can  be  added.  One  technique  involves  adding  a  data  base 
for  the  particular  component's  state,  e.g..  some  options  controlling  the  presenter’s  style,  and 
constructing  presenters  and  recognizers  for  showing  and  manipulating  it.  Alternatively,  a 


data  base  of  commands  for  the  component  can  be  added,  just  as  in  tlie  previous  section  a 
command  data  base  was  addeil  for  the  application  data  bitse. 


1.3  Describing;  iVescn(a(ion  Systems 

Ihe  prcscnuition  system  model  can  be  used  as  a  descriptive  tool.  Che  model  provides  a 
set  of  concepts  for  enumerating  and  categori/ing  basic  functions  and  interactions  in  a  user 
interface,  even  when  that  interface  wiis  not  designed  with  the  model  in  mind. 

In  chapter  four  several  user  interfaces  will  be  described  using  the  presctiuition  system 
model.  The  selection  exhibits  a  variety  of  interface  styles  in  order  to  illustrate  the  model's 
generality.  In  each  example  the  focus  will  be  on  those  presentation  system  mechanisms  that 
play  the  most  important  part  in  defining  that  particular  style.  Two  interfaces,  drawn  from 
tliose  described  in  chapter  four,  arc  sketched  below. 

Xerox  Star  /  Apple  Lisa.  Ilie  Xerox  SLar  [Smith,  Irby.  Kimball,  Verplank  &  Harslem  83] 
and  the  Apple  Lisa  [Lisa  84]  systems  offer  an  interface  using  icons  -  pictorial  presentations 
of  commands  and  data.  Some  recognition  is  .simple  reference  resolution  such  as  pointing  to 
an  icon  that  presents  a  particular  command.  Other  recognition  involves  more  complicated 
inter-icon  relations  such  as  proximity.  For  example,  in  l.isa  the  user  deletes  a  file  by 
moving  the  file’s  icon  to  a  trash  can  icon.  In  both  Star  and  Lisa  the  user  prints  the  file  by 
moving  its  icon  to  the  printer  icon. 

Emacs  Dired.  A  subsystem  of  the  Emacs  editor  [Stallman  81],  Dired  is  used  to  perform 
various  directory  operations.  It  is  an  example  of  an  extended  presentation  system  that 
provides  both  d/reef  manipulation  of  the  data  biisc  (the  directory  being  edited),  e.g.,  when 
certain  file  properties  arc  changed,  and  planned  operations,  e.g.,  when  files  are  marked  for 
later  deletion.  1  he  planned  deletions  arc  presented  as  annotations  to  the  presentation  of  the 
airrent  directory. 
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1.4  PSHasc:  A  Presentation  System  liasc 

Chapter  five  tiisciisscs  PSftasc.  the  prototype  presentation  system  btise  that  was 
implemented  in  the  course  of  this  research. 

PSltase  explicitly  incorporates  the  presentation  system  model  structure.  It  includes  Ux)ls, 
mechanisms,  and  ready-made  parts  for  building  an  interface  consisting  of  an  application 
data  ba.se.  presentation  data  base,  presenters,  recognizers,  and  presentation  editor.  IXimain- 
independent  and  style-independent  mechanisms  arc  provided  and  may  be  combined  largely 
independently.  I  hese  characteristics  cause  PSUase  to  be  useful  in  constructing  a  wide  range 
of  interfaces. 

Figure  1-4  shows  the  overall  structure  of  PSBase.  The  data  base  mechanisms  provide 
support  for  building  application  data  bases  struetured  in  a  network  somewhat  similar  to 
knowledge  representation  networks.  The  network  includes  descriptions  of  the  classes  of 
objects  as  well  as  the  objects  themselves,  and  cliiss  inheritance  is  supported.  An  important 
poirif  is  th'.i.t  this  network  is  used  to  bijjld  the  presc.ntation  data  base  as  tve!!,  a.nd  the 
presentation  and  application  data  bases  arc  linked  together  into  a  large,  uniformly 
structured  data  base.  1  his  uniformity  is  an  impoiiant  factor  in  tlic  power  of  the  PSBiisc 
mechanisms.  PSBase  predefines  a  large  part  of  the  presentation  data  base  class  network. 

PSBase  also  provides  mechanisms  that  accompany  the  presenuition  data  base:  Graphics 
redisplay  ensures  that  the  presentation  data  base  is  continuously  displayed  on  the  terminal. 
Several  presentation  editor  functions  arc  provided;  the  interface  builder  may  select  these,  as 
desired. 

I  hc  presenter  support  and  recognizer  support  modules  provide  a  variety  of  tools  and 
mechanisms  for  creating  and  controlling  prexsenters  and  recognizers.  Most  important  among 
these  mechanisms  is  a  language  for  describing  presentation  styles  and  general  presenters 
that  interpret  these  languages.  The  interface  builder  need  only  describe  how  the 
prcsentatioti  structure  relates  to  the  application  data  base  structure,  and  the  presenters 
perform  the  actual  creation  and  updating  of  the  presentations. 


Figure  1-4:  SiruclureofPSBase 


A  number  of  basic  style  packages  olTer  specific  cx^mponcius  of  liv^main-indcpcndcnt 
inlcvfacc  styles  that  the  interface  builder  may  chtxisc  to  include.  Some  general  presenters 
and  recognizers  are  provided.  Kor  example,  a  presenter  is  provided  to  produce  command 
menus.  As  another  example,  a  recogni/er  is  provided  to  interpret  simple  rule  ilc.seriptions 
in  order  to  recognize  icon  movement,  similar  to  the  Xerox  Star  and  Apple  l  isa  systems  (see 
section  1.3). 

No  claim  is  made  that  PSRiise  would  serve  as  a  production  presenuvtion  system  base.  It  is 
a  prototype,  and  needs  more  and  improved  features  of  many  kinds.  It  provides  only  a  part 
of  the  presentation  editor  functions  that  would  be  needed.  Many  more  domain- 
independent  presenters  and  recognizers  could  be  included.  The  presentation  style 
description  language  could  be  improved  and  used  to  drive  recognition  as  well.  This  would 
result  in  more  uniformity  in  what  the  system  can  present  and  what  it  can  rectjgnizc. 
providing  the  user  with  increased  consistency  and  power. 

1.5  Coaslructiii};  User  Interfaces 

In  order  to  demonstrate  the  utility  of  PSBase,  three  interfaces  were  constructed  using  the 
PSBase  mechanisms  and  tools.  The  three  interfaces  share  the  stime  application  data  base, 
but  embody  different  styles.  The  first  style  uses  icons,  similar  to  the  Xerox  Star  and  Apple 
Lisa  system  described  in  section  1.3.  The  second  style  uses  text  displays  with  accompanying 
command  menus.  Ihc  third  style  is  a  graphical  annotation  style,  an  extension  of  the  Dired 
style  described  in  section  1.3. 

Some  of  the  work  wiis  done  once  and  shared  between  die  three  implementations,  namely, 
the  style-independent  development  of  the  application  data  base.  Once  that  work  was 
completed,  implementing  a  particular  style  was  largely  a  matter  of  writing  a  few  small  pieces 
using  PSBase  tools  and  choosing  some  standard  PSBase  ready-made  parts  from  the  basic 
style  packages  module. 


1.6  Related  Work 

Ihis  report  diseusscs  two  developments,  a  domain-independent,  style-independent 
presentation  system  biise  for  building  user  interfaces,  and  its  uiulerlying  model  of  user 
interfaees.  Ihisseelion  discusses  characteristics  of  the  base  and  the  model  that  distinguish  it 
from  other  research,  fwo  characteristics  of  both  the  base  and  the  model  are  particularly 
important: 

First,  the  model  and  the  base  attempt  to  concentrate  on  general  mechanisms,  independent 
of  any  particular  domain  and  independent  of  any  particular  style.  The  intent  htis  been  that 
they  should  be  free  of  value  judgments  concerning  styles.  Discussing  what  constitutes  a 
good  style  or  developing  new  styles  arc  separate  cnbrts;  this  rcsctirch  offers  a  conceptual 
vocabulary  in  which  such  a  discussion  can  be  phrased  and  offers  a  base  for  c.vpcrimcnting 
with  or  combining  alternative  styles. 

Second,  the  model  and  the  base  center  tibout  the  high-level  concept  of  the  presentation. 
This  concep'  c'^risidors  the  semantic  connection  between  the  screen,  t'.nd  the  application. 
Ihc  model  is  structured  to  show  how  the  prescnuition  is  used  tis  a  medium  for 
communication  between  the  user  and  the  application.  The  emphasis  in  both  the  model  and 
the  presentation  system  btisc  has  been  on  the  system  aspects:  how  the  system  of  processes 
aiul  data  bases  arc  structured  and  interact  regarding  the  presentation  relationship.  This 
research  h;is  not  emphasized  any  one  particular  part  of  this  system:  several  other  studies 
cmplKisize  Ute  application  data  base,  or  the  presentation  data  b;isc,  or  presenters,  or 
recognizers. 

Other  research  that  this  work  resembles  can  be  classed  into  three  broad  aretis:  huntan 
factors,  systems  and  tcchnic|ucs,  and  presentation  systems.  Although  this  research  is  related 
to  these  areas,  the  author  knows  of  no  other  research  that  directly  addresses  the  same  goals 
of  studying  and  providing  sup|K)rt  for  a  system  of  general  user  interfaces  mechanisms. 
Rather  than  being  an  alternative  approach,  this  work  complements  the  others  that  are 
mentioned.  1  he  third  area,  presentations  systems,  is  Uie  closest  to  this  research,  in  that  its 
includes  systems  for  aiding  user  interface  wnsiruciion,  based  on  concepts  similar  to  the 
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prescntalion  concept  used  licre. 


Human  Factors.  At  the  psychological  end  of  the  spectrum,  there  have  been  several 
efforts  to  which  this  research  is  somewhat  related.  Two  major  kiiuls  of  work  is  described, 
first,  user  modeling  and,  second,  interface  specification  lechniL/ues  and  guidelines.  Some 
representative  research  is  mentioned. 

There  have  been  efforts  to  develop  models  of  user  behavior,  user  performance,  and  user 
understanding  of  systetns.  Often  these  studies  concentrate  on  particular  classes  of  users  or 
interface  styles.  Shneiderman,  for  example,  has  examined  a  class  of  interface  styles  that  he 
terms  direct  manipulation  [Shneiderman  83].  These  interfaces  are  marked  by  "visibility  of 
the  object  of  interest;  rapid,  reversible,  incremental  actions;  and  replacement  of  complex 
command  language  sytitax  by  direct  manipulation  of  the  object  of  interest."  He  discusses 
direct  manipulation  style,  and  its  affect  on  and  acceptance  by  different  kinds  of  users,  in 
terms  of  a  semantic/syntactic  model  of  user  behavior  [Shneiderman  &  Mayer  79] 
[Shneiderman  80],  According  to  this  model,  two  kinds  of  knowledge  about  user  interfaces 
reside  in  long-term  memory,  syntactic  and  semantic.  Syntactic  knowledge  includes  details 
of  command  syntax;  it  has  an  arbitral^  character  and  is  easily  forgotten  unless  frequently 
used.  Semantic  knowledge  includes  the  hierarchically-structured  concepts  of  functionality 
and  processes  for  performing  various  tasks.  Semantic  knowledge  is  largely  independent  of 
particular  systems  and  is  more  easily  retained.  The  success  of  the  direct  manipulation  style 
follows  from  the  fact  that  "the  object  of  interest  is  displayed  so  that  actions  are  directly  in 
the  high-level  problem  domain,"  requiring  little  need  for  syntactic  knowledge. 

Modeling  the  user  can  be  a  tool  for  evaluating  tlie  behavioral  style  of  an  interface,  by 
studying  the  match  between  the  interface  behavior  and  the  user  behavior.  The  presentation 
system  nunlel,  on  the  other  hand,  complements  the  user  model  by  approaching  die  problem 
from  the  other  end.  discussing  the  kinds  and  internal  structures  of  interface  mechanisms 
that  will  by  their  interaction  produce  the  particular  overall  behavior  as  seen  by  the  user. 

Some  guidelines  and  formal  techniques  have  been  ilevelopcd  for  specifying  user  interface 
dialogs,  a  part  of  the  user  interface  style,  formal  grammars  (or.  equivalently,  state  transition 
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networks)  arc  one  Icchniqiic  for  describing  and  designing  the  dialog  between  user  and 
computer  [Reisner  81][Reisner  82]  [RIeser  &  Foley  82]  [Jacob  82]  [Rrown  82],  Formal 
grammars  describe  the  interaction  between  user  actions  and  system  responses.  Some 
grammars  include  cognitive  information,  describing  what  a  user  has  to  learn  and  remember. 
A  grammar  can  be  used  tis  a  design  UX')I.  evaluating  designs  for  consistency  and  simplicity. 
Problems  usd's  might  have  and  mistakes  they  might  make  can  be  predicted. 

As  with  user  models,  dialog  deseriptions  arc  complemented  by  the  work  reported  here. 
One  may  identify  three  layers  of  study,  all  requiring  models  and  description  techniques: 
general  user  interface  mechanisms  (presentation  system  model),  overall  user  interface  style 
(dialog  spccincations),  and  the  user  (user  models). 

Systems  and  rcchniqucs.  The  second  area  of  related  work  is  die  building  of  systems, 
from  cooperative  user  interfaces  to  graphics  systems,  and  the  development  of  techniques  to 
use  in  such  .systems.  Some  of  these  projects  tend  to  concentrate  on  one  side  or  the  other  of 
the  presentation  relation:  on  reiirescnting  the  knowledge  in  the  application  data  base  or  on 
manipulating  and  displaying  the  presenUition  data  base.  Others  lend  to  concentrate  on  ihc 
development  of  particular  interface  styles. 

Research  into  cooperative  user  interfaces,  such  as  the  Cousin  effort  at  CMU  [Flayes  84] 
and  the  Consul/Cuc  effort  at  Information  Sciences  Inslilule  [Kac/marck,  Mark  & 
Wilezynski  S.J]  [Mark  81],  study  various  ways  that  user  interface  can  be  more  easily 
constructed  to  actively  aid  tlic  user.  An  important  part  of  such  systems  is  the  provision  of  a 
uniform  view  of  the  applications  and  a  helpful  assistant,  based  on  an  c.xtensive  description 
of  those  applications  or  the  interface  styles.  Such  an  assistant  might  try  to  imdcrstatid  why 
die  user  is  having  difficulty  or  try  to  understand  requests  made  in  an  unexpected  form. 

A  large  part  of  the  Consul/Cuc  work  concentrates  on  the  representation  of  knowledge 
about  the  application  and  its  commands  (services).  Fhc  different  applications  arc  described 
in  a  uniform  manner.  'Fhis  is  separated  from  the  particular  choice  of  styles  used  to  interface 
to  these  applications,  such  as  window's/pointing,  command  languages,  or  natural  language. 
1  he  user  interface  lussistant  understands  the  data  base  representation  and  uses  it  to  provide 


cxphinjilioiis,  llcxible  recovery  from  comni;ind  language  errors,  and  assistance  in  using 
several  dirfereni  applications  by  understanding  their  functionality. 

The  research  reported  here  is  closer  to  the  Cousin  project.  1  he  Cousin  project  does  not 
concentrate  on  incorporating  knowledge  about  application  semantics,  but  rather  on 
developing  a  uniform  interface  style  to  support  a  user  interface  assistant.  The  assistant 
corrects  eiToneous  or  abbreviated  input,  interacts  with  the  user  to  resolve  errors,  and  offers 
integral  and  automatically  generated  on-line  help  and  documentation.  The  Cousin  system 
provides  a  common  interfiicc  base,  separate  from  the  application,  that  interprets  an  interface 
definition  provided  by  the  application  builder.  This  definition  exprcs.scs  the  user  interface 
as  a  set  of  forms,  with  fields  that  convey  information  between  the  user  and  the  application. 

There  is  an  emphasis  in  these  research  efforts  on  developing  cooperative  styles, 
developing  techniques  for  them  (such  as  more  intelligent  recognizers),  and  for  Consul/Cue, 
investigating  the  problems  of  representing  knowledge  about  the  application's  functionality. 
I  hc  work  reported  in  this  report  also  relies  heavily  on  the  separation  and  uniformitv  of  the 
application  data  base  mechanism.  But  this  work  has  not  studied  tlic  issues  of  kitowledge 
representation  involved.  Nor  hsis  it  been  involved  with  developing  particular  styles.  And 
unlike  the  cooperative  systems  projects,  this  work  attempts  to  be  able  to  model  and  support 
arbitrary  e.xisting  interface  styles. 

There  arc  several  research  efforts  studying  different  uniform  styles  of  information 
presentation  and  interaction,  and  several  efforts  at  developing  presentation  and  interaction 
techniques  for  specific  domains.  For  example,  spatial  data  base  management  systems 
[Herot  80]  [Donclson  78],  the  Boxer  system  [diScssa  85],  tltc  Xerox  Star  [Purvy,  Farrell  & 
Klose  83]  [Smith.  Irby,  Kimball.  Verplank  &  Harslcm  83].  and  tlie  Query-by-Example- 
hased  office  systems  [Zloof  82]  (Zloof  &  dc  Jong  77]  all  offer  the  user  a  consistent  way  of 
interacting  with  a  variety  of  applications.  In  a  spatial  data  base  management  system,  tlie 
user  accesses  information  by  "moving  through"  the  data  base  -  information  from  many 
different  domains  is  organized  spatially,  with  related  information  nearby.  Retrieval  is 
something  like  Hying  over  a  land  of  information:  information  is  found  by  moving  to  it.  <uid 


detail  is  controlled  by  AX^niing.  In  the  Query-by-l  AanipIc  systems,  on  the  other  hand,  the 
user  accesses  different  kinds  of  information  by  providing  an  example  of  the  kind  of 
information  desired.  Several  systems  have  been  developed  that  offer  complex  presentation 
techniques  and  styles  for  particular  domains.  Simulators  arc  perhaps  the  most  widely 
known;  the  Steamer  .system  [Stevens.  Roberts  &  Stead  83].  discus.sed  in  chapter  four,  is  one 
example.  Another  area  of  increasing  interest  is  the  presentation  of  the  organization  and 
execution  of  programs,  such  as  the  Computer  Corporation  of  America's  program 
visualization  system  [CCA  79],  Henry  Lieberman’s  Tinker  system  [Liebcrman  84] 
[l.icbcrman  83].  and  the  Brown  University  system  for  program  animation  [Brown  & 
Scdgcwick  84a]  [Brown  &  Sedgcwick  84b]  [Brown  &  Sedgewick  84e].  The  intent  of  the 
work  reported  in  this  report  is  to  develop  a  model  and  system  that  can  be  used  to  describe 
and  build  any  of  these  kinds  of  styles. 

The  books  by  Newman  and  Sproull  [Newman  &  Sproull  79]  and  Foley  and  Van  Dam 
(Foley  &  Van  Dam  82]  primarily  discuss  low-level  drawing  and  interaction  techniques  for 
gi'ctpIiiCS  jyatCiViS.  For  the  most  p<ii  t.  they  are  conccriicd  with  only  one  kind  of  appliealion 
data  base  --  geometric  models  of  solids,  surfaces,  etc.  Within  the  framework  of  the  model  of 
this  report,  their  books  discuss  detailed  techniques  for  building  presentation  editors  and 
presentation  data  bases.  However,  concerning  the  presentation  data  base,  their  emphasis  is 
more  on  representation  at  a  low  level,  suitable  for  display  processors,  and  docs  not  attempt 
to  offer  a  general  representation  technique.  This  is  in  contrast  to  the  presentation  system 
ba.se  of  chapter  five,  for  example,  which  uses  a  general  description  mechanism  for  both  the 
presentation  data  biisc  and  the  application  data  base.  The  stiuidard  graphics  systems  are  less 
in  need  of  such  a  scheme,  <is  they  arc  not  involved  with  any  sort  of  "reasoning"  about  the 
data  bases,  and  instead  need  to  perform  computations  efficiently.  I'hus.  the  graphics  system 
should  be  viewed  as  a  low-level  component  of  a  presentation  data  biise  as  described  in  this 
report. 

Information  Presentation  Systems.  I  he  research  reported  in  this  report  most  closely 
resembles  research  developing  what  have  been  called  Information  presentation  systems  or 
systems  for  automatically  synthesizing  graphics  environments,  for  example  the  Bharat  system 


[Gnanamgari  81],  tiie  View  system  [Friedell  83],  and  the  AlPS  system  (/.dybel.  Gibbims, 
Greenfeld  &  Yonke  81]  [/dybel,  Greenfeld,  Yonkc  &  Gibbons  81],  (  hese  systems  all 

emphasi/c  a  knowledge-based  approach  to  creating  what  this  report  would  call  iniclligenl 
presenters.  The  systems  explicitly  incorporate  concepts  similar  to  the  presentation  concept 
used  here,  particularly  the  AlPS  system.  All  three  systems  have  interesting  and  individual 
aspects,  but  from  the  point  of  view  of  this  research,  it  will  suffice  to  discuss  the  AlPS  work 
iis  representative.  (It  wiis  while  working  with  the  AlPS  group  that  the  author  first  started 
thinking  about  the  presenuition's  use  as  an  organizing  concept  for  modeling  user  interfaces.) 


The  goal  of  AlPS  tis  an  information  presentation  system  is  to  provide  an  interface  to  a 
large  knowledge  base  or  know  ledge- based  system.  The  systent  automatically  generates 
displays  from  content-oriented  (i.e.,  domain)  specifications.  (F..g.,  "display  the  ships  in  the 
Mediterranean.")  AlPS  is  itself  a  knowledge-based  system.  Using  a  large  knowledge  base 
describing  how  structures  of  domain  information  can  be  related  to  structures  of  graphical 
displays,  the  system  automatically  selects  or  constructs  an  appropriate  presentation  style.  A 
full  iiiforiViutiOu  prcsciluitiori  sy-stem  would  iiicludc  kiiowlcdgc  about  the  user,  geiiera! 
domains,  a  wide  variety  of  presentation  styles,  and  human  factors  decisions  involved  in 
graphical  display. 


There  are  three  ttspects  in  which  the  work  reported  in  tliis  report  differs  from  the  AlPS 
research.  First,  this  report  addresses  a  more  general  class  of  interfaces  than  information 
presentation  systems.  Information  presentation  systems  currently  exist  only  in  prototype 
form;  there  arc  many  other  kinds  of  interfaces  to  be  supported  now  and,  presumably,  even 
when  full  information  prcsenUition  systems  arc  available.  Most  interfaces  do  not  have 
intelligent  or  automatic  presenters.  One  rcncclion  of  this  difference  is  .seen  in  the  general 
model  of  interfaces  developed  in  this  report. 


Second,  this  report  emphasizes  the  system  aspects  of  the  interface,  rather  than 
concentrating  on  any  one  component  of  the  .system.  TTtis  is  one  reason  why  this  research 
and  the  others  arc  complementary:  the  AlPS  work  considers  presenters  in  detail;  this  work 
considers  the  relationship  between  presenters  and  the  rest  of  the  user  interface  system. 
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rhiril,  the  most  ciisliiiguishing  di;iracleristic  of  the  AlPS  work  is  ils  emphasis  on  issues  of 
knowledge  representaiion.  Ihis  report  does  not  address  those  issues,  again  heeause  the 
emphasis  here  is  not  on  intelligent  presenters  or  on  techniques  of  describing  presentation 
styles.  Relatively  simple  description  techniques  sufllce  for  the  PSRase  system.  Ihiwcvcr, 
die  results  of  research  into  the  rcpreseiUatirHi  of  knowledge  about  graphical  display  could  be 
incorporated  into  a  production  version  of  a  presentation  system  base  to  grctil  effect. 


Chapter  I’wo 

I  he  Primitive  Preseiitiition  System  (PPS)  Model 


I  his  chapter  discusses  the  HI’S  model  in  detail,  f  igure  2  1  reproduces  llgure  1-3  of 
chapter  one,  except  that  here  two  new  primitixe  signal  inputs  are  added,  controls  for  the 
presenter  and  recognizer.  Kach  of  die  components  of  the  PHS  model  will  be  discussed  in 
turn  in  sections  below. 

2.1  PPSCalc 

The  sections  in  this  chapter  use  an  example  program  called  PHSCalc.  This  is  a  simple 
spreadsheet  program,  a  trivial  veision  of  VisiCalc  (Beil  82j.  PPSCalc  w.is  designed 
spccincally  for  this  explanation  --  its  behavior  strictly  follows  the  PPS  model.  PPSCalc  is 
iiiusiraicu  in  figures  2-2  and  2-3. 

llic  spreadsheet  consists  of  cells,  organized  in  rows  and  columns.  Each  cell  may  be 
empty,  contain  just  a  numeric  value,  or  contain  a  formula  and  a  numeric  value.  In  a  cell 
with  a  formula,  the  numeric  value  is  computed  by  the  formula  from  the  values  in  other  cells. 
Cells  which  Just  have  a  numeric  value  --  no  formula  -  are  called  independent  cells.  Their 
values  arc  set  by  the  user.  Cells  which  have  a  fonnula  are  called  dependent  cells.  Their 
values  arc  recomputed  periodically,  as  will  be  discussed  below.  Cells  with  neither  a  formula 
nor  a  value  arc  empty. 

PPSCalc  has  two  display  modes,  formula  display  and  value  display,  illustrated  by  the  two 
figures.  F  igurc  2-2  shows  the  mode  that  displays  the  dependent  cells'  formulas.  Figure 
2-3  shows  the  mode  displaying  the  dependent  cells'  values  computed  by  those  formulas. 

PPSCalc  is  shown  in  figure  2-2  with  an  assignment  of  cell  formulas  for  computing  a 
simple  bill,  based  on  the  prices  for  two  kinds  of  items  and  the  numbers  of  the  items 


Figure  2-2:  PPSCalc  --  Fomnila  Display 
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Figure  2-3:  PI’SCalc  --  Value  Display 


Durchased.  The  A I  and  A2  independent  cells  specify  the  prices,  and  the  B1  and  B2 
independent  cells  specify  the  number  purchased.  Dependent  cells  Cl  and  C2  compute  the 
amount  to  be  paid  for  the  two  items,  and  dependent  cell  C3  computes  the  total  amount  to 
be  paid.  Cells  A3  and  133  arc  empty. 

In  both  display  modes,  the  visible  contents  of  the  cells  can  be  edited,  using  the  tc.\t  editor 
Fmacs.  After  a  certain  amount  of  editing,  typically  just  changing  the  contents  of  one  cell, 
the  user  types  the  return  key.  This  signals  PPSCalc  to  update  the  spreadsheet  based  on  the 
edits  to  the  visible  text.  Recalculation  is  then  performed:  each  dependent  cell,  from  left  to 
right,  top  to  bottom,  has  its  formula  evaluated  and  its  numeric  value  recalculated.  After 
that,  the  visible  text  is  updated  to  display  any  of  the  cells  that  changed. 

For  example,  the  user  might  edit  the  ”5"  in  the  B2  cell  display  to  be  "H",  in  order  to 
indicate  that  1 1  items  of  the  second  kind  are  being  purchased,  instead  of  5.  1  he  display  now 
looks  like  figure  2-4. 


The  user  types  a  return,  and  PPSCalc  recalculates  the  dependent  cells  Cl.  C2,  and  C3.  C2 


BE 


20 


Bmi] 


Figure  2-4:  PPSCalc  --  After  Fdiling 

changes  its  value  because  of  n2.  and  C3  because  of  C2.  PPSCalc  redisplays  the  spreadsheet. 


showing  the  new  bill,  2is  in  figure  2-5. 
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Figure  2-5:  PPSCalc  --  After  Recalculation 


The  user  now  decides  to  change  the  cell  formulas,  to  add  accumulation  of  a  5  percent 
siilcs  tax.  The  user  requests  the  formula  display  mode,  types  formuhis  into  the  previously 
empty  A3  and  B3  cells,  and  edits  the  formula  in  the  C3  cell.  Cell  A3  totals  the  amounts,  cell 
B3  computes  the  sales  tax,  tind  cell  C3  computes  the  total  charge.  Tlus  is  illustrated  in  figure 
2-6. 
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When  the  user  switches  back  to  displaying  the  dependent  values,  these  new  fornuilas 
result  i»i  the  display  shown  in  figure  2-7. 
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Figure  2-7:  PPSCalc  --  Values  of  New  Formulas 


A  question  arises  as  to  what  should  happen  when  dependent  values  are  being  displayed, 
and  the  user  edits  a  dependent  value  to  a  different  numeric  value.  PPSCalc  has  two  modes 
regarding  this.  In  one  mode  PPSCalc  will  ignore  the  edit  --  when  the  user  types  return, 
PPSCalc  beeps,  recomputes  the  dependent  value  normally,  and  displays  the  result.  In  the 
other  mode  PPSCalc  interprets  the  edit  as  changing  that  dependent  cell  to  be  an 
independent  cell  with  that  value. 

PPSCalc  will  be  further  discussed  in  the  sections  below  as  it  is  used  to  illustrate  issues  in 
presentation  system  modeling. 

2.2  The  Application  Data  Base 

A  user  interface  does  not  exist  by  itself  -  its  whole  purpose  is  to  provide  the  user  with  the 
ability  to  use  something,  typically  a  program  or  system  of  programs.  It  may  also  be 
something  that  the  user  docs  not  cx'iisidcr  to  be  an  active  agent  --  for  example,  a  collection 
of  values,  or  in  general  a  data  base.  In  some  applications  the  user’s  view  is  of  a  passive  data 
base,  even  though  in  the  background  (external  or  internal  to  the  data  base)  there  is  some 
active  agent  managing  the  data  ba.se.  For  example,  typically  a  user  will  view  a  file  system  as 
passive,  though  in  the  background  various  operating  system  programs  maintain  the  integrity 
and  reliability  of  the  file  system.  (Backup  and  s;ilvagcr  programs  arc  examples.) 

Any  application  can  be  viewed,  from  the  perspective  of  the  user  interface,  as  a  data  base. 


In  other  words,  inteifacing  to  a  data  base,  besides  being  an  iniporiaiil  case  in  iiselT,  can 
siimdate  llie  situation  with  other  applications.  For  example,  consider  a  user  interface  to  an 
application  program  where  there  is  no  obvious  data  base  in  the  imidementation.  One  such 
example  is  a  prcKess  control  system,  allowing  the  user  to  monitor  and  control  the  state  of  a 
power  generator.  s;iy.  Here,  much  of  the  state  is  not  in  the  program  but  in  the  physical 
world:  temperatures,  pressures,  etc.  However,  from  the  point  of  view  of  the  user  interface, 
the  behavior  of  the  application  program  is  similar  to  the  behavior  of  a  data  base.  I  he  system 
can  thus  be  treated  ;is  a  system  that  maintains  a  data  base  describing  this  world  state  and  the 
control  options.  In  the  model  the  job  of  the  user  interface  system  is  to  let  the  user  view  and 
manipulate  this  world  description. 

Since  any  applieation  can  be  viewed  as  a  daUi  btise,  for  the  model  developed  in  this  report 
we  will  treat  the  user  interface  eis  providing  the  user  with  access  to  a  data  base.  'Hie  user’s 
Uisk  will  be  to  view  and  manipulate  the  contents  of  the  data  base. 

The  PPSCalc  spreadsheet  can  be  considered  a  data  base.  It  has  an  active  component. 
iKuiiely  recalculation,  which  determines  the  values  of  the  dependent  cells  in  the  spreadsheet 

World  .Models.  Ihe  basic  data  base  model  being  used  does  not  specify  anything  about 
the  internals  of  what  is  being  called  the  application  data  base.  It  only  matters  that  the  data 
base  takes  commands  and  queries  and  returns  observables.  Nothing  is  .said  about  whether 
the  data  base  is  implemented  by  information  records,  or  by  computation,  or  by  connection 
to  the  physical  world.  Its  external  behavior  is  that  of  a  data  base. 

It  may  well  be  reasonable  (o  iniplcment  an  application  that  connects  to  physical  objects 
by  having  a  world  model,  i.c.,  an  explicit  description  of  the  world.  This  situation  is  really 
Just  an  extension  of  the  primitive  presentation  model  proposed  for  the  user  interface.  Here 
the  world  model  data  ba.se  is  a  representation  of  the  outside  world.  Figure  2-8  shows  tliis 
modulari/ation  of  the  implementation. 

In  this  approach  programs  (and  not  only  programs  of  the  user  interface  system)  deal  with 
a  data  base  describing  the  relevant  parts  of  the  physical  world.  Separately,  the  world  model 


presenter  and  reeogni/er  perform  the  job  of  keeping  the  wt)rlcl  model  up  to  date  and 
elTeeting  changes  to  the  physical  world  as  the  world  model  is  manipulated.  The  interface  to 
the  physical  world  is  much  like  an  interface  to  another  data  base.  Instead  of  c|ueries.  there 
are  ct)mmands  to  sensors;  instead  of  data  base  observables,  there  is  the  information  returned 
by  those  sensors.  Instead  of  data  bicsc  commands,  there  are  commands  to  efTectors.  the 
hardware  that  performs  some  physical-world  action. 

Cascaded  Interfaces.  This  approach  to  modulari/ing  a  system  can  just  as  well  apply  to  the 
case  where  there  is  another  data  base,  instead  of  the  physical  world.  In  this  case  one  set  of 
programs  (user  interface  programs  in  the  special  case)  view  and  manipulate  one  data  biisc, 
which  is  a  representation  of  a  second  data  ba.se,  viewed  and  manipulated  by  ;mother  set  of 
programs. 

I'his  is  not  a  symmetrical  communication  between  two  groups  of  programs.  The  second 
set  of  data  base  programs  arc  generally  unaware  of  the  first  set  -  the  first  data  base  is 
intended  to  serve  as  an  extended  interface  to  the  second,  i.c..  main,  data  base.  In  the  special 
case  of  die  user  interface,  ideally  the  application  programs  are  unaware  or  at  least  not 
dependent  on  the  structure,  style,  or  operation  of  the  presentation  data  base  and  its 
asscK'iated  programs. 

As  a  final  note  on  this  asymmetry,  consider  the  presenter  and  recognizer  in  die  user 
interface.  They  arc  not  under  shared  responsibility  of  user  and  application  program  --  both 
are  acting  entirely  for  the  user,  under  the  user's  control.  The  entire  user  interface  subsystem 
is  an  internal  agent  of  the  user,  not  :ui  impartial  intermediary  between  two  equal 
communicators. 

2.3  The  J*rc.scnlalion  Data  Itase 

We  now  consider  the  other  components  of  the  PPS.  those  strictly  within  the  user  interface 
system.  The  presentation  data  base  is  the  symbrilic  description  of  the  screen  comprising 
presentations  and  their  properties  and  relations;  it  conveys  information  about  the  data  ba.se. 

I  hough  it  is  not  the  purpose  of  this  research  to  .study  in  detail  such  representation  issues. 


this  section  will  itlcntify  the  basic  properties  of  presentation  sirnclnrc  that  concern  a 
presentation  system. 

Ihe  Simplicity  of  Two  Data  liases.  An  interface  containing  two  data  bases,  the 
presenlalion  data  base  and  the  application  data  b;»sc.  may  at  first  seem  to  be  more  complex 
for  the  user  than  the  rudimentary  data  base  user  interface  di.sciissed  in  chapter  one. 
However,  the  situation  for  the  user  is  actually  much  better  in  a  PPS  user  interface. 

Many  of  the  details  of  the  application  data  base's  interface  are  hidtlen  from  the  user.  The 
application  data  base  still  has  an  interface  of  commands,  queries,  and  observables,  but  the 
user  does  not  deal  with  that  interface  --  only  the  presenter,  recogni/cr  and  any  outside 
programs  do.  The  user  is  no  longer  concerned  with  the  access  and  organization  of  the 
application  data  biise  --  the  user  deals  only  with  the  presentation  data  base. 

fhe  presentation  data  base  hits  a  more  direct  interface  than  the  mdimentary  data  b;ise 
model  did.  Tlie  presentation  editor  has  Uiken  the  place  of  the  command  transducer.  The 
commands  for  presentation  editing  are  chosen  to  be  convenient  for  the  user.  Kor  example, 
they  might  include  a  base  of  general  text-editing  commands,  so  that  the  user  docs  not  have 
to  learn  a  special  language  for  a  particular  application  data  btise. 

Also,  as  mentioned  above,  the  presentation  data  base  is  in  a  form  directly  viewable  by  the 
user.  There  is  essentially  no  need  for  queries  to  the  presentation  data  base,  since  the 
presentation  is  directly  and  continuously  viewed.  There  are  only  a  few  vestigial  queries, 
remaining  in  the  form  of  viewing  commands  to  scroll  the  screen,  for  example. 

Name  Prc.scntations.  Name  prc,scntations  are  the  most  fundamental  of  presentations, 
conveying  no  other  information  other  than  the  identity  of  a  data  base  object.  Complex, 
structured  presentations  arc  built  out  of  name  presentations.  In  PPSCalc,  column  names 
(e.g.,  "A")  arc  examples  of  name  presentations  presenting  a  particular  column.  Single  digits 
arc  name  presentations  presenting  the  numbers  0  through  9.  f-'ornuila  operation  symbols 
(e.g.,  "  +  ")  arc  name  presentations  presenting  particular  arithmetic  operations. 


Name  proscntalions  do  not  have  parts  or  properties  that  are  also  presentations.  A  name 
presentation  may  have  striieturc,  e.g.,  smaller  text  or  graphical  forms  that  are  part  of  it,  but 
any  parts  are  not  in  themselves  presenting  domain  information,  for  example,  from  the 
point  of  view  of  a  map.  the  letters  in  the  name  "lloston".  while  parts  of  the  text  string,  tio 
not  individually  pre.scnt  information. 

Composite  I’rcscntutions.  Composite  presentations,  on  the  other  hand,  have  grtiphical 
structure  in  which  a  larger  presentation  is  constructed  from  smaller  presentations.  Ihc 
composite  presentation  as  a  whole  presents  some  domain  informativ)n.  tinil  in  aildition  some 
of  its  parts  or  properties  present  domain  information  as  well.  Generally,  the  hierarchical 
structuring  of  sub-presentations  into  a  composite  presentation  follows  a  similar  structure  of 
the  information  in  the  data  base.  For  example,  the  entire  PPSCalc  text  table  is  a 
presentation  of  the  s|ireadshcet.  I  he  presentation  is  composed  of  text  string  presentations 
for  the  values  and  formulas  of  cells,  and  those  cells  in  turn  are  parts  of  the  spreadsheet. 

In  PPSCalc  the  presentation  "A2"  is  composed  of  the  name  pre.sentations  ”A”  and  "2". 
pre.senting  column  and  row.  Tlie  presentation  "A2"  as  a  whole  presents  a  particular  cc’>  or 
the  value  contents  of  it  Similarly  the  numeral  presentation  "75"  is  composed  of  digit 
prcsenlalions.  However,  the  presentation  "75"  is  generally  not  just  a  presentation  of  the 
number  75  --  in  figure  2-2  on  page  30,  for  example,  it  is  a  presentation  of  the  number  in  the 
A2  cell,  i.e.,  a  presentation  of  a  properly  of  or  fact  about  the  A2  cell.  It  is  the  value  of  this 
property  that  is  the  number  75.  The  presentation  style  here  presents  the  property  by 
presenting  its  value.  It  is  essentially  a  composite  presentation  composed  of  just  one  sub- 
presentation. 

Composite  presentations,  as  well  as  name  presentations,  may  have  parts  or  properties  that 
arc  not  in  themselves  presentations.  For  example,  the  overall  I’PSCalc  presentation  htis  the 
grid  as  one  of  its  parts.  The  grid,  however,  is  not  a  presentation.  It  serves  a  purpose  in  the 
overall  presentation  --  it  makes  the  communication  more  effective  -  but  it  is  not  itself 
presenting  anything  in  the  data  Ixise.  It  is  a  kind  of  template,  in  which  pre.sentations  arc 
placed.  A  common  example  of  template  presentations  is  a  bibliographic  reference,  such  as 
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"[Cai  roll65]".  I  he  brackets  are  a  part  of  the  composite  presentatiot).  but  do  not  present 
anything.  The  parts  ’’Carroll”  and  ”65".  on  the  other  hand,  are  presentations. 

Relations  and  I’roperties.  Relations  between  presentations  and  properties  of 
presentations  can  themselves  convey  information.  Presentation  stylo  frcc|iiently  imiioses 
strong  conventions  on  such  ”non-objcct”  presentations.  A  relation  between  two 
presentations,  such  as  nearness,  alignment,  or  comparative  size,  can  be  chosen  to  convey 
information,  frequently  reinforcing  information  presented  in  some  otlier  way.  A  property 
of  a  presentation,  such  as  its  size,  color,  font,  position,  or  direction,  can  similarly  present 
information.  Ihe  information  presented  by  tlie  property  is  usually  very  closely  related  to 
the  information  presented  by  the  presentation  form,  just  as  composite  presentation  structure 
generally  follows  domain  structure. 

PPSCalc  as  shown  above  Inis  no  example  of  property  presentations.  However,  if  it  were 
to  display  dependent  values  in  a  manner  different  from  independent  values,  e.g.,  in  a 
different  font,  the  font  of  the  text  would  be  a  property  presentation.  Many  examples  of 
property  prescniaiions  can  be  found  in  road  maps.  A  line,  for  example,  pre.scnts  a  particular 
road,  and  the  line's  color  presents  the  class  of  road  (highway,  street,  dirt  road).  Frequently, 
a  property  presentation  presents  a  property  of  the  object  presented  by  the  presentation 
form.  For  example,  the  color  of  an  area  of  a  map  may  present  the  amount  of  rainfall  in  the 
geographical  area  presented. 

One  common  relation  presentation  is  alignment  used  to  present  .some  kind  of  similarity. 
In  other  words  it  shows  that  the  domain  objects  presented  by  the  aligned  presentations 
share  some  common  property.  In  the  PPSCalc  example,  the  fact  that  ”75”  is  aligned  with 
”100”  above  indicates  that  the  cells  whose  contents  arc  presented  are  both  in  the  same  data 
base  column. 


2.4  l  lic  I’rcsenliUion  Kditor 


1  he  proseruations  can  be  directly  edited  by  the  user  by  means  of  tlie  presentation  editor. 
It  allows  the  user  to  manipulate  the  forms  on  the  screen,  creating  new  forms  or  changing  or 
(.Icleting  existing  ones.  It  combines  capabilities  of  a  te.xt  editor  with  those  of  a  graphics 
(diagram)  editor.  As  changes  are  made,  their  results  are  immediately  visible. 

(Jraphics  Redisplay.  Ihc  scrccit  is  continually  updated  to  rcnect  changes  in  the 
prc.sciitation  data  base,  in  a  prtK'ess  allied  graphics  redisplay.  It  is  this  process  that  involves 
traditional  graptiics  (drawing)  routines.  Graphics  redisplay  is  in  effect  another  prcxsentiition 
system.  Utking  the  information  in  the  presentation  data  base,  expressed  in  terms  of  symbolic 
gniphic  forms  (text,  circles,  lines,  etc.),  and  converting  it  to  a  data  base  of  pixels,  for 
instance. 

This  report  will  not  concentrate  on  this  level  of  presentation  system,  for  two  reasons. 
First,  it  has  been  studied  extensively  elsewhere  (Newman  &  Sproull  79]  [Foley  &  Van  Dam 
S9]  Secopcf  it.  is  i.'si.ially  not  the  level  at  which  the  user  is  interacting  coneeptnally.  The 
user  typically  does  not  think  about  or  use  commands  that  are  defined  in  terms  of  pixels,  but 
rather  in  terms  of  symbolic  forms.  These  symbolic  forms  are  the  ones  that  present  the 
application  data  biisc.  A  presentation  style  presents  a  number  as  text,  for  example,  but  it 
does  not  matter  whether  the  graphics  system  chooses  a  bitmap  or  vector  display  technique 
to  present  that  text  on  the  screen. 

2.5  The  Presenter 

The  presenter  process  models  the  decisions  and  actions  of  constructing  or  updating  a 
presenuition.  The  presenter  can  be  divided  into  three  major  parts,  the  domain  collector,  the 
semantic  presenter,  and  the  organizational  presenter,  as  shown  in  figure  2-9. 

This  division  of  the  presenter  allows  the  identification  and  study  of  its  basic  functions  and 
the  interactions  between  them.  They  am  be  classillcd  by  the  kind  of  knowledge  the 
functions  depend  upon:  knowledge  about  the  structure  of  information  in  the  application 
data  base,  knowledge  about  the  mapping  between  domain  information  and  the  presentation 
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data  biisc.  atul  knowledge  about  purely  visual  considerations. 


riic  domain  collector  rinds  and  intcrprcLs  the  relevant  part  of  the  data  base.  I  he  domain 
collector  understands  the  organi/alion  of  the  applieation  liala  base,  the  ipiery  language,  and 
the  format  of  the  observables.  It  is  the  part  of  the  presenter  that  connects  with  the  data 
bcise.  Given  the  specification  of  what  is  to  be  selected,  it  constructs  the  needed  queries  and 
passes  them  to  the  data  base.  The  observables  (or  parts  of  them)  are  then  assembled  into 
the  information  needed  by  the  semantic  presenter. 

1  he  domain  collector  thus  has  knowledge  about  the  kind  of  domain  information  that  will 
be  relevant  for  the  user  interface,  and  about  the  way  that  infoniiation  is  represented  in  the 
application  data  base.  It  does  not,  on  the  other  hand,  know  anything  about  the  way  such 
information  will  be  presented  to  the  user.  In  PPSCalc  the  domain  collector  accesses  the 
internal  variables  that  implement  the  data  base  cells,  collecting  the  formuhis  or  cell  values 
for  use  by  the  semantic  presenter. 

The  .semantic  presenter  embodies  the  primary  mapping  from  data  base  domain  to  visual 
domain,  the  kind  of  mapping  specified  by  a  map  legend,  for  example.  It  specifics  the 
particular  visual  elements  (text  strings,  circles,  lines,  etc.)  to  be  used,  atid  those  relationships 
between  them  that  directly  convey  data  base  information.  It  may  partially  specify  some  of 
these  relationships,  e.g.,  that  some  text  siring  (a  label)  should  be  near  some  other  object, 
leaving  the  organizational  presenter  to  specify  the  exact  position  (taking  into  account  purely 
spatial  relationships,  such  as  overlap  and  clutter). 

In  PPSCalc  the  semantic  presenter  converts  the  numeric  values  and  formulas  (formulas 
are  stored  in  the  data  base  as  small  programs)  to  text  strings.  It  also  creates  the  text  strings 
that  label  the  rows  and  columns. 

fhe  organizational  presenter  imposes  purely  visual  organization  on  the  presentation.  The 
organizational  presenter,  unlike  tlic  semantic  presenter  and  the  domain  collector,  is  domain- 
independent.  It  uses  knowledge  about  spatial  layout  and,  more  generally,  about  improving 
the  effectiveness  of  visual  communication.  It  uses  various  tabular  layouts,  alignment. 


positioning  to  avoid  chiltcr.  fonts,  spacing,  and  highlighting.  The  scnianlic  presenter  might 
sometimes  partially  specify  some  of  these,  c.g..  specifying  that  some  text  or  graphic  form 
should  be  highlighted.  The  organi/ational  presenter,  however,  has  the  job  of  pinning  down 
these  speeilleations.  It  typically  takes  into  account  the  other  forms  that  will  be  on  the 
screen.  Once  the  semantic  presenter  has  made  its  typically  kxal  decisions  about  visual 
styles,  the  organizational  presenter  reasons  about  the  larger  groups  of  fomis  and  their  visual 
intcnictions. 

This  view,  that  the  presenter  stages  successively  restrict  the  specilication  of  the  visual 
presentation,  can  be  extended  into  the  presentation  data  base  itself.  Part  of  the  Job  of  the 
presentation  data  base  is  to  maintain  a  scTcen  image  reHecting  tiie  presentation  information. 
As  discussed  in  section  2.4,  this  is  a  task  of  traditional  graphics  packages.  I'hcy  too  restrict 
the  specification  of  the  visual  presentation,  e.g.,  determining  which  pixels  arc  to  be  set  or 
choosing  fonts  if  not  otherwise  specified. 

In  PPSCalc  the  organizational  presenter  uses  a  tabular  layout  for  the  overall  presentation. 
The  organizational  presenter  also  is  responsible  for  creating  the  table's  grid.  (Some  much 
more  intelligent  organizational  presenter  might  decide  whether  or  not  to  use  a  grid, 
embodying  various  kinds  of  human  factors  knowledge.  The  decision  is  fixed  in  PPSCalc.) 
Within  the  grid  cells,  numeric  values  are  aligned  in  one  style  (right  ends  of  the  number 
strings  aligned),  and  formul.'is  arc  aligned  in  another  style  (left  justified  in  the  cell). 

One  issue  not  discussed  in  chapter  one  is  user  control  of  the  presenter  and  recognizer. 
The  presenter  hiis  an  input,  called  presenter  control.  This  is  a  primitive  command  signal 
interface  to  the  presenter  that  controls  the  style  it  uses  and  what  it  will  present  from  the  data 
base.  In  PPSCalc  there  is  just  one  such  control,  a  key  that  toggles  whether  fomuilas  or 
dependent  values  arc  presented.  In  general,  there  may  be  different  presenter  control  inputs, 
affecting  the  three  componenLs  of  the  presenter. 
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2,6  I  lie  Recognizer 

l  lic  rccogni/cr  process  observes  the  user's  editing  of  tlie  screen  presentations  and 
interprets  this  as  manipulation  of  the  data  base.  As  with  presenters,  rccogni/.ers  are  divided 
into  three  major  parts,  namely,  the  organisational  recogni/er.  the  semantic  recognizer,  and 
the  domain  changer,  as  shown  in  tigurc  2-10. 

Hie  organizational  recognizer  ideniincs  the  spatial  relationships,  presentations,  and 
actions  upon  them  that  arc  relevant.  It  imposes  a  syntactic  structure  on  the.se. 
Organizational  recognition  is  generalized  parsing.  Text  parsing  is  a  special  case;  the  more 
general  organizational  recognition  works  with  text,  graphical  forms,  visual  properties  and 
relationships,  and  editing  actions.  In  general,  the  organizational  recognizer  is  looking  for 
changes  to  the  presentation  structure  from  the  user’s  editing. 

The  semantic  recognizer  translates  the  syntactic  structure  into  a  scmtmtic  structure 
dc.scribing  changes  to  the  data  base  information.  Generally  this  involves  assigning 
intpinrpt  ttjons  to  the  text  forms,  graphic  forms,  sp.atia!  properties,  spatial  relationships, 
editing  actions,  and  the  syntactic  relationships  among  these  elements. 

The  separation  of  recognition  of  presentation  structure  from  recognition  of  the  semantic 
structure  can  be  seen  in  the  division  of  natural  language  parsers  and  compilers  into  syntactic 
and  scmiuitic  modules. 

The  domain  changer  translates  this  description  of  changes  into  the  actual  data  base 
commands  necessary  to  effect  those  changes. 

In  PPSCalc  the  organizational  recognizer,  when  considering  the  presentation  structure  for 
the  presentation  of  the  C2  cell's  formula,  for  instance,  starts  by  finding  the  position  where 
tliis  presentation  is  IcKatcd  within  the  grid  presentation.  It  tlien  parses  the  formula  from  the 
surrounding  spaces  and  decomposes  it  into  tokens  (e.g.,  "A2".  and  "112").  The 
semantic  recognizer  converts  this  into  the  program  required  for  tlie  data  base  cell.  The 
domain  changer  performs  the  actual  modifications  of  the  internal  variables. 


The  PPSCalc  example  jiisl  given  illustrates  only  a  special  case  of  reci)gnition.  namely 
recognition  based  on  just  the  visible  presentations,  the  results  of  whatever  editing  took 
place.  This  special  case  is  very  similar  to  the  representation  shift  model  discussed  earlier, 
and  is  an  inverse  operation  to  that  of  the  presenter.  However,  the  more  general  kind  of 
recognition  lakes  account  of  the  editing  actions  tis  well.  Different  edits  that  produce  the 
s;ime  result  might  be  recogni/ed  as  different  changes  to  the  data  base.  (Whether  such 
recognition  is  performed,  or  the  extent  to  which  it  is  performed,  depends  on  the  particular 
application  and  user  community.  But  a  general  model  should  be  able  to  account  for  such 
behavior.) 

Consider  some  examples  in  PPSCalc.  Suppose  that  the  spreadsheet  is  currently  in  the 
state  corresponding  to  figures  2-2  and  2-3  on  page  30.  The  user  is  viewing  dependent 
values,  as  in  figure  2-3.  Consider  the  possible  recognition  when  the  user  moves  the  "2375" 
in  the  C3  cel!  to  the  A3  cell,  c.g.,  by  deleting  the  text  in  the  C3  cell,  and  undeleting  it  into 
the  A3  cell.  The  presentation  tliat  results  is  shown  in  figure  2-11. 
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Figure  2-11:  PPSCalc  -- 
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Value  Moved 

One  possible  recognition  style  is  similar  to  the  representation  shift  model  in  that  it  only 
depends  on  the  visible  result.  It  would  rccogni/c  this  ;u>  two  changes,  first  that  the  C3  cell 
become  empty,  and  second  that  the  A3  cell  be  given  an  independent  value  of  2375.  This  aise 
is  indistinguishable  from  that  where  the  user  typed  into  the  A3  cell  instead  of 

moving  that  text  into  the  A3  cell. 

However,  another  recognition  style  might  treat  that  move  of  "2375"  as  moving  what  the 
"2375"  presents  --  the  dependent  value  computed  by  the  formula  Cl-f  C2.  Thus  moving 
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the  "2375"  from  llic  C3  cell  lo  the  A3  cell  might  be  recognized  as  the  two  actions,  first  that 
the  A3  cell  be  given  the  C3  cell's  formula  Cl  +C2,  and  second  that  the  C3  cell  be  emptied 
(as  before).  The  visible  result  is  as  in  figure  2-11  above.  However,  switching  into  the  mode 
displaying  formulas  shows  the  different  effect  of  the  recognition; 


ABC 

1 
2 
3 


A  similar  kind  of  recognition,  providing  an  effect  found  in  commercial  spreadsheet 
programs  such  as  VisiCalc,  is  to  recognize  certain  copy  actions  as  meaning  that  tlie  formula 
be  partially  copied  --  but  with  changes  based  on  the  row  or  column.  For  instance,  stiy 
during  tlic  initial  creating  of  the  spreadsheet  the  user  had: 


1 

2 
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If  the  user  now  uses  a  copy-with-changes  command  to  copy  the  "Al*Br’  formula 
presentation  from  the  Cl  cell  to  the  C2  cell,  recognition  would  interpret  this  as  putting  the 
formula  A2*B2  into  the  C2  cell,  (fhe  references  to  row  1  have  been  changed  to  row  2.) 

Uefcrcncc  and  Recognition.  An  important  class  of  presentation  editor  commands  arc 
those  providing  the  user  with  the  ability  to  refer  to  text,  graphic  forms,  areas,  or  positions  on 
the  screen.  Fxamples  include  pointing  devices  such  as  Uiblets  and  "mice."  1  here  arc  other 
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Figure  2-13:  PPSCalc  -  Preparing  to  Copy  Formula 
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Figure  2*12;  PPSCalc  -  Formula  Moved 


possibilities,  such  as  using  arrow  ko,s  lo  move  a  poimer  aroiiiul  the  screen,  or  keyboard 
commands  that  refer  to  positions,  quadrants,  etc.  by  name  or  coordinates.  1  he  reference 
capabilities  provided  by  a  pointing  device  can  be  exteiuled  by  tracking  the  pointer,  thus 
achieving  the  ability  to  refer  to  arciis  or  groups  of  forms,  for  instance.  Although  reference 
docs  not  change  the  visible  prcsenuitiotis,  it  is  an  impoi  tant  editor  action  since  it  undergoes 
recognition. 

PPSCalc  could  be  extended  to  include  reference  recognition.  For  example,  a  reference  to 
an  independent  value  presentation  could  be  recognized  ;is  a  command  to  increment  that 
value.  As  another  example,  a  reference  to  a  cell  containing  a  formula  and  then  to  a  blank 
cell  could  be  recognized  as  a  command  to  copy  the  formula  to  the  second  cell.  (This  could 
perhaps  include  changes  to  accommodate  different  columns  and  rows  as  mentioned  earlier). 

When  Recognition  Happens.  In  the  PPS  model  recognition  happens  continually  and  is  in 
effect  over  the  entire  screen  (i.e.,  over  the  entire  presentation  data  base).  The  intent  is  that 
the  screen  continually  present  the  state  of  the  data  base,  providing  the  user  with  direct 
manipulation  of  the  data  base  by  continual  presenter  and  recognizer  action.  Some 
presentation  editor  command  sets  may  allow  such  continuity  at  the  granularity  of  single 
commands,  i.e.,  allow  recognition  to  happen  after  every  single  command.  However,  in 
general  there  may  be  groups  of  commands  that,  taken  together,  fono  a  larger  atomic  unit 
from  the  recognizer's  point  of  view. 

For  instance,  in  PPSCalc  the  recognizer  is  not  be  able  to  act  upon  a  partially  typed, 
syntactically  incomplete  formula  such  as  ")  f  A2".  (It  would  be  possible,  though,  to  have  a 
more  tolerant  organizational  recognizer  --  in  this  case  parser  --  that  allows  tliis  string  and 
assigns  some  sort  of  Interpretation  to  it,  such  as  the  interpretation  for  "(0)  +  A2".)  In 
PPSCalc  typing  the  return  key  signals  the  end  of  an  atomic  edit.  After  each  return,  the 
recognizer  is  invoked,  the  data  ba.se  changed,  the  presenter  invoked,  and  the  presentation 
data  base  updated. 

Recognizer  Controls.  Figure  2-10  on  page  44  shows  recognizer  controls,  a  primitive 
command  signal  that  affects  the  operation  of  the  recognizer.  In  PPSCalc  a  single-key 


comniaiiLl  toggles  how  the  rccogni/or  will  treat  ctliLs  of  a  dopciuleiit  value  (for  the  mode 
when  depeiulcnt  values,  not  rormiila.s,  are  displayeil).  One  choice  is  to  treat  the  edit  as  an 
error  and  just  ignore  it.  I  he  other  choice  is  to  treat  the  edit  as  changing  that  cell  to  be  an 
independent  cell  with  that  value.  (  The  formula  is  erased.)  In  general,  there  may  be 
recognizer  control  inputs  for  each  of  the  recognizer  components. 


2.7  riic  Rcprc.senlalion  Shift  Model  and  Direct  Manipulation 

The  representation  shift  model,  introduced  in  chapter  one,  is  a  special  case  of  the  PPS 
model.  It  is  shown  in  figure  2-14.  In  the  representation  shift  model,  the  presentation  data 
btise  contains  all  and  otdy  the  information  in  the  application  data  base.  As  a  result,  the 
presenter  and  recognizer  have  simpler,  more  restricted  Uisks.  The  presenter  gets  a 
representation  of  the  entire  application  data  base,  converts  it.  and  loads  the  entire 
presentation  data  base.  The  recognizer  hits  the  opposite  operation:  the  recognizer  gets  a 
representation  of  the  entire  presentation  data  base,  converts  it,  and  lotids  the  entire 
uppliCtUion  di'.t?.  b?.sc. 

The  represcnttiiion  shift  model  and  the  PPS  model  embody  different  mcltiphors.  In  the 
representation  shift  metaphor  the  presenter  creates  a  picture  of  the  data  base.  The  user  edits 
the  picture.  At  the  end  of  an  atomic  edit,  the  rccogniz.er  makes  the  data  base  be  what  is 
depicted.  In  the  PPS  metaphor  the  presenter  creates  a  picture  of  typically  a  small  view  of  a 
subset  of  the  data  base.  The  user  edits  the  picture.  The  recognizer  watches  how  the  user 
makes  the  changes  and  changes  the  data  b;isc  in  the  same  way. 

In  the  representation  shift  model,  the  presentation  data  base  must  contain  all  the 
information  in  the  ajiplication  data  base.  This  is  equivalent  to  stiying  that  the  entire 
application  dtita  ba.se  bo  viewed.  (And  because  of  this  restriction,  the  converter  am  .simply 
load  the  entire  application  dat;i  base  from  its  translations  of  the  presentation  data  base.) 
This  restriction  can  be  inefficient  for  large  data  ba.scs  or  when  rapid  user  interaction  with 
the  application  is  desired.  Ihc  restriction  is  unacceptable  when  the  size  of  tlic  data  base  gets 
so  large  that  the  time  to  perform  the  translation  cycle  bctw'ccn  the  application  and 
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prcscntiilion  data  bases  is  slower  than  the  desired  interaction  lime.  It  also  leads  to 
inconvenient  visual  clutter:  the  user  cannot  view  just  a  relevant  poiiion  of  the  data  b;Lse. 
I'his  is  a  serious  problem  for  complex  data  bases.  The  ability  to  control  the  selection  of 
information  to  be  viewed  and  the  way  it  is  to  be  viewed  can  be  crucial.  However,  for  small 
application  data  bases,  the  represeiUatioti  .shift  model  can  be  advantageous  by  virtue  of  its 
great  simplicity. 

Because  of  the  no-formula  display  mode,  PPSCalc  is  not  presenting  all  the  information  in 
the  application  data  base.  (  The  data  base  is  the  collection  of  spreadsheet  cells).  PPSCalc  is 
therefore  not  simply  a  representation  shift  i  interface,  and  must  be  modeled  with  the  full 
PPS  model.  However,  if  the  display  of  spreadsheet  cells  were  modillcd  to  show  holh  the 
formula  and  the  value,  PPSCalc  could  be  modeled  as  a  representation  shift  interface. 

Because  of  the  restriction  that  the  presenLation  '  aa  base  convey  all  the  infomiation  in  the 
application  data  base,  the  representation  shift  model  has  another  difference  from  the  PPS 
model  "  the  representation  shift  recognizer  need  only  look  at  the  current  stale  of  the 
presentation  data  base,  not  the  sequence  ofcifiling  operations  that  produced  it.  J  he  editing 
operations  cannot  matter:  if  two  editing  actions  result  in  the  stime  visual  data  base  stale, 
they  must  be  equivalent. 

For  example,  there  can  be  no  difference  between  (1)  moving  a  presentation  from  one 
place  to  another  and  (2)  first  deleting  that  presentation  and  then  creating  at  the  second 
position  a  new  presentation  that  looks  exactly  like  the  first  one.  Similarly,  there  can  be  no 
such  thing  as  renaming  an  object  by  editing  its  name.  Fdiiing  its  name  must  be  equivalent 
to  deleting  the  object  and  then  creating  a  new  one  with  the  second  name.  In  fact  renaming 
really  has  no  meaning  for  the  application  data  base,  since  it  is  produced  completely  from  the 
recognizer's  data.  In  other  words,  all  the  objects  arc  created  anew. 

For  the  full  PPS  model  we  a.ssume  that  the  presentation  data  ba.se  conveys  only  a  subset 
of  the  information  in  the  application  data  bjjse.  often  a  small  subset.  The  representation 
shift  model  can  be  slightly  extended  to  apply  to  some  cases  of  subset  presentation.  When 
the  subset  of  the  application  data  base  is  separable  from  the  rest  of  the  application  data  base. 


i.c..  there  are  no  references  into  or  out  of  the  subset,  the  presentation  data  base  can  show  all 
the  inlbrnitition  of  tliat  part  of  the  application  data  base.  In  elTecl.  that  subset  is  being 
treated  as  an  entire  application  data  base  in  its  own  right. 

The  restriction  of  the  F’HS  model  that  produces  the  representation  .shift  model  can  be 
summari/ed  by  examining  the  functions  between  the  presentation  and  application  data 
bases,  as  defined  by  tlie  presenter  aiul  recognizer  operations.  Define  the  pre^vnler  function 
to  be  the  mapping  of  presentation  data  base  states  from  ai^plication  data  base  states  ;is 
produced  by  the  presenter.  Similarly,  define  the  recognizer  function  to  be  the  mapping  of 
application  data  base  slates  from  presentation  data  base  states  as  produced  by  the 
recognizer. 

The  presenter  function  must  be  invertible,  so  that  the  presentation  data  base  conveys  all 
the  inibrmation  about  the  tipplication  data  base.  The  recognizer  function  is  an  extension  of 
the  presenter's  inverse.  The  recognizer  generally  extends  the  inverse  for  the  convenience  of 
the  user;  the  user  can  create  any  of  severtil  variations  on  the  form  that  the  Dresentor  would 
have  chosen,  l-'or  example,  the  PI’SCalc  recognizer  allows  latitude  in  positioning  of 
formulas  within  cell  prescnt<itions,  even  though  the  presenter  always  aligns  the  formuhts 
with  the  left  edge  of  the  cell.  We  can  say  that  there  are  generally  sets  of  presentation  data 
base  slates  that  are  equivalent;  the  presenter  produces  only  one  of  these  states,  but  the  user 
and  the  recognizer  interpret  the  others  as  conveying  the  same  information. 

In  the  PPS  model,  however,  the  presenter  and  recognizer  functions  arc  of  a  different 
•■<ature,  because  of  the  need  to  allow  operations  on  only  partial  presentations,  fhe  major 
difference  is  that  the  domtiin  of  the  recognizer  function  is  not  the  range  of  the  presenter 
function.  I  he  presenter  maps  from  application  data  base  to  presentation  data  biise.  The 
recognizer,  however,  maps  from  sequences  of  prc.senlation  editing  commands  to  sequences 
of  data  ba.se  commands.  I'igure  2-15  shows  a  schematic  form  of  tlie  PPS  model  that 
highlights  these  mappings. 

A  restriction  is  phiced  on  the  decoupling  of  the  presenter  and  recognizer  functions  in  the 
full  PPS  moilel.  I  his  restiiction  gives  the  PPS  model  a  vlirect  maiii|)ulation  style  similar  to 
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the  style  of  the  representation  shift  model.  The  restriction  can  be  slated  by  expanding  the 
notion  of  inverse  presenter  and  recognizer  functions,  as  discussed  for  the  representation 
shift  model: 

Consider  sequences  of  pre.sentalion  editing  commands  as  functions,  mapping  one 
presentation  dat;i  base  state  to  another.  Similarly,  sequences  of  data  b;ise  commands  map 
one  application  data  base  state  to  another.  If  P  is  the  presenter  relation.  R  is  the  recognizer 
relation,  and  C  is  any  particular  atomic  presentation  editing  command  scciuenec,  the 
restriction  can  be  stated  in  the  following  form  (using  for  function  composition  tmd 
"  =  =  "  for  equivalence  of  two  presentation  data  base  states  due  to  recognizer  tolertince): 

C*  P  ==  P*R(C) 

In  other  words,  the  editing  commands  C  acting  on  a  presentation  data  base  created  by  the 
presenter  P  should  result  in  the  same  presentation  data  base  as  would  result  from  the 
presentation  of  the  application  data  base  that  results  from  recognition  of  those  editing 
commands. 

There  are  interfaces  where  the  style  of  recognition  is  very  different  from  the  style  of 
prcscnUition  --  i.e.,  the  above  rule  is  not  even  approximated.  In  such  an  interface  the  editing 
action  may  directly  but  temporarily  result  in  a  presentation  data  base  state  very  different 
from  what  the  presentation  dtita  base  will  be  after  recognition  and  presenter  update.  This 
report  does  not  attempt  to  argue  whether  such  a  user  interface  style  is  good  or  bad,  nor  docs 
the  restriction  on  the  PPS  model  eliminate  such  a  user  interface  from  consideration.  Rather, 
the  restriction  changes  the  way  the  user  interface  would  be  modeled  --  it  cannot  be  modeled 
cis  a  PPS.  The  techniques  di.scusscd  in  chapter  three  can  be  used,  however,  to  model  such  a 
user  interface  as  an  extended  presentation  system.  In  particular  it  will  be  modeled  as  a 
combination  of  one  PPS  capturing  the  presentation  ;md  another  PPS  capturing  the 
recognition.  By  modeling  the  user  interface  as  an  extended  system,  the  very  different  nature 
of  presentation  and  recognition  is  highlighted. 


Chapter  Three 

Constructing  Larger  Presentation  System  Models 


rhis  chapter  shows  how  the  primitive  presentation  system  (I’PS)  model  can  be  extended 
to  model  more  complex  presentation  systems.  Chapter  four  contains  .several  examples  of 
complex  presentation  system  models  of  existing  user  interfaces.  The  basic  technique  for 
extending  a  presentation  system  model  is  to  attach  iui  additional  presentation  system  to  it, 
either  replacing  or  augmenting  some  part  of  it.  The  resulting  presentation  system  may  thus 
contain  several  smaller  presentation  systems.  Ihc  particular  extensions  discussed  in  this 
chapter  are  suggested  by  an  examination  of  the  major  limitations  of  the  PPS  model: 

*  1  he  user  can  only  make  immediate  chanses  to  tlie  data  base  --  there  is  no 
planning. 

*  'I'ho  iKjer  c^n  othy  see  the  cwre^it  stole  of  the  application  data  base  resulting 
from  the  commands  to  change  it  --  there  is  no  presentation  of  the  commands 
themselves  or  the  differences  between  states. 

*  The  user  can  only  interact  with  the  presenUition  editor,  presenter,  and 
recognizer  through  primitive  signals  -  there  are  no  presentation  system 
interfaces  to  tJicsc  components. 

Each  of  these  limittitions  suggests  a  particular  extension.  The  limitations  and  the 
extensions  are  discussed  in  the  following  sections. 

3.1  Adding  a  Planned  Data  Base 

1  he  first  major  limitation  of  the  PPS  model  is  that  it  only  allows  immediate  changes  to  the 
application  data  base.  In  the  PPS  model,  as  the  user  edits  the  presenUition,  continual 
recognition  causes  the  application  data  base  to  change  accordingly.  This  can  be 
inconvenient  if  the  user  would  like  to  sec  what  the  result  looks  like  before  committing  to  it. 
Immediate  change  can  also  be  a  more  serious  problem  if  the  application  data  base  changes 


arc  irreversible.  This  is  Dflen  ihc  ease  when  an  application  program  or  physical  pitxicss  is 
being  controlled  through  the  data  base,  rhcreforc.  if  the  presentation  system  model  is  to 
siippi.)it  ihc  constriiclion  of  user  interfaces  where  the  user  can  postpone  the  effects  of 
commands  -  i.e..  where  the  user  can  plan  clianges  --  the  IM’S  nn>del  must  be  e.vtended. 

One  method  of  postponing  changes  is  to  add  a  new.  sccoiul.  data  base  that  is  a  future  (i.e., 
planned)  version  of  the  original  data  base.  'I'his  is  illustrated  in  llgurc  3-1.  fhe  user  can  edit 
the  planned  version's  presentation,  separate  from  the  presentation  of  the  actual  data  base, 
and  when  the  planned  version  looks  acceptable,  give  a  "do  it"  command  that  causes  the 
actual  data  ba.se  to  be  updated.  The  "do  it"  command,  like  the  other  commands  affecting 
the  application  data  base,  emanates  from  die  recognizer,  fhe  user  may  cause  this  to  happen 
either  by  a  direct  recognizer  control  signal  or  by  performing  some  presentation  editing 
command  that  is  recognized  as  a  "do  it." 

In  general  the  planned  version  of  the  application  data  base  will  behave  similarly  to  the 
actual  data  base,  ideally  reproducing  all  the  active  components.  For  example,  in  PPSCalc  a 
planned  data  base  ideally  would  include  all  the  recalculation  capabilities  of  the  actual  data 
base.  When  this  is  the  case,  the  user  does  not  lose  power  or  convenience  in  manipulating 
die  planned  version  over  what  the  user  would  have  had  manipulating  the  actual  data  base. 

As  with  the  other  extensions  discussed  in  this  chapter,  this  is  only  an  illustration  of  the 
technique  of  extending  a  presentation  system  to  achieve  some  goal.  This  extension 
technique  may  be  used  in  combination  with  other  presentation  system  structures. 

For  example,  figure  3-2  shows  a  combination  of  the  straightforward  PPS  model  and  the 
future  data  bitse  model  discussed  above.  This  combination  allows  the  user  to  have  two 
presentations  tit  once,  one  showing  the  future  version  of  the  data  base,  the  other  showing  the 
current  version  of  the  data  base.  With  two  .separate  presentations  and  presentation  editors, 
the  user  can  interact  with  both,  planning  some  changes  and  effecting  some  changes 
immediately. 


3.2  Addiiii’  a  Data  Base  of  Conimands 

The  second  major  limilation  (dThe  Pl^  inoilel  is  that  the  user  cannot  see  a  description  of 
the  changes  or  the  commands  to  effect  them  presented  explicitly.  I  he  PI’S  model  offers  the 
user  a  feeling  of  direct  manipulation  of  the  application  data  base  contents.  fU)wevcr.  it  is 
sometimes  stifcr  or  more  convenient  to  see  and  edit  a  command  or  a  description  of  the 
change  to  be  made.  So.  aUh;)ugh  direct  manipulation  is  becoming  more  and  more  common 
and  is  undeniably  useful,  a  complete  model  must  support  the  construction  of  interfaces  in 
which  change  is  described  or  seen.  Some  systems  may  offer  a  combination  of  direct 
manipulation  and  command  editing.  Others  may  offer  the  ability  to  sec  or  prescribe  the 
kinds  of  changes  desired  --  goals  --  without  specifying  the  particular  operations  needed  to 
achieve  these  goals. 

Instead  of  adding  a  planned  version  of  the  data  base,  with  content  and  presenUition  style 
mirroring  the  actual  data  base,  a  data  base  of  the  plans  or  commatids  themselves  can  be 
added.  In  this  extension,  the  planned  changes  are  represented  in  the  new  data  base 
explicitly  and  can  be  presented  in  a  style  different  from  that  of  the  actual  data  base. 

Figure  3-3  shows  an  extended  presentation  system  in  which  the  user  can  interact  witli  the 
application  data  base  directly,  via  the  PPS  at  the  lop  of  the  llgurc,  and  also  indirectly,  by 
giving  commands  to  the  application  data  base  via  the  PPS  at  the  bottom  of  the  figure.  1  he 
bottom  PPS  has  a  data  base  containing  commands  for  the  application  data  base  above.  1  he 
user  can  sec  and  edit  these  commands  presented  in  the  presentation  data  base  in  the  bottom 
PPS.  When  the  user  gives  the  "do  it"  command,  these  data  btisc  commands  arc  passed  to 
the  application  data  base. 

Thus  this  extension  also  gives  the  user  a  planning  capability,  and  is  similar  in  structure  to 
the  previous  extension  in  that  a  new  data  base  has  been  added  its  a  buffer.  The  difTerence  is 
that  the  data  base  in  this  case  has  commands,  whereas  in  the  previous  case  it  was  a  copy  of 
the  application  data  base. 

As  in  the  future  dtita  ba.se  extension,  the  figure  shows  two  copies  each  of  the  presentation 


editor,  prescmatioii  data  base,  presenter,  and  recogni/er.  I'hoiigh  their  general  purpose  is 
the  same  and  they  are  labeled  the  same,  they  are  in  general  dirferent.  In  this  extension  this 
is  especially  the  case  for  die  presenters  and  rccogni/crs.  The  application  data  base  in  the  top 
PPS,  and  the  data  base  of  commands  in  the  bottom  PPS,  have  very  diflereiU  kinds  of 
information  in  them.  I'he  pre.sentation  and  recognition  styles  will  therefore  in  general  be 
quite  different. 

3.3  Adding  Interfaces  to  PPS  (  omponents 

The  third  major  limitation  of  the  PPS  model  is  that  the  presentation  editor,  presenter,  and 
recognizer  are  not  presented.  The  user  controls  them  through  presentation  editing 
commands,  presenter  controls,  and  recognizer  controls.  There  are  two  aspects  to  this 
problem  in  the  PPS  model: 

First,  these  controls  arc  only  primitive  signals,  such  as  keystrokes.  There  is  no  ability  to 
sec  the  commands  the  user  is  typing,  edit  them,  or  get  help  in  their  use.  The  only  thing 
being  seen  tind  cditetl  (i.e.,  presented)  is  the  application  data  b;ise. 

Second,  the  user  must  give  commands  to  alTect  the  editor,  presenter,  tuid  recognizer.  The 
user  cannot  directly  sec  the  state  of  those  processes,  their  modes,  control  variables,  etc.  As 
the  user  interface  becomes  more  powerful  and  complex,  the  user  interface  components,  as 
well  as  the  application  data  base,  become  important  objects  to  present.  T  he  text  editor 
Emacs,  for  instance,  has  nearly  fifty  options  variables  in  its  simplest,  initial  form.  Many 
systems  have  many  option  variables  controlling  presenter  style,  modes,  etc. 

Instead  of  primitive  signals  to  control  the  presentation  editor,  presenter,  and  recognizer, 
and  no  ability  to  present  their  state,  PPS  interfaces  to  these  components  can  be  added.  This 
involves  adding  a  data  base  for  the  particular  component’s  state  (e.g.,  a  data  biusc  of  the 
presenter's  options  controlling  its  vE.  .  yie)  or  using  the  previous  technique  of  adding  a 
data  b;tse  for  the  component's  commands. 

Figure  3-4  shows  one  such  interface,  providing  a  representation  shift  interface  to  the 
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Figure  3-4:  Presenter  Interface  Kxtension 
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presenter.  Ihe  prcsenler's  state  has  been  expanded  into  a  data  b;Lse  presented  by  the 
representation  shift  presentation  system  at  the  top.  As  with  all  the  additional  presentation 
systems  in  this  chapter,  there  are  many  possible  presentation  systems  that  eoiild  be  added. 
A  PI’S  eonid  have  been  used  instead  of  the  representation  shift,  for  example. 

In  this  e.xtended  presentation  system  the  user  ean  interaet  sviih  the  application  data  base, 
via  the  main  presentation  system  at  the  bottom.  Ihc  user  can  al.so  interact  with  the 
presenter,  via  the  presentation  system  at  the  top,  which  has  replaced  the  original  presenter 
control  input.  The  user  can  change  the  way  the  presenter  behaves  by  editing  the  presenter’s 
state  presentation.  For  instance,  this  might  include  changing  the  amount  of  detail  shown  in 
the  pre.sentation  of  the  application  data  ba.se.  It  might  include  changing  how  the  presenter 
shows  diflerent  kinds  of  domain  information,  e.g.,  whether  tables  or  graphs  arc  used. 
Finally,  it  might  include  changing  what  parts  of  the  application  data  base  are  being 
presented.  (Recall  that  the  PPS  model  allows  that  the  application  data  biise  to  be  only 
partially  presented.) 

Figure  3-5  shows  an  alternative  extension  for  controlling  the  presenter.  Here,  instead  of 
editing  the  presenter's  state,  the  user  edits  commands  to  the  presenter,  just  as  in  the 
previous  .section  the  technique  was  used  to  allow  the  user  to  give  comntands  to  the 
application  data  base.  I  ho  top  presentation  system  (again  a  representation  shift  model,  but 
as  before  it  could  be  any  kind  of  presentation  system)  hooks  directly  into  the  presenter 
control  input  to  the  presenter. 

This  technique  of  ailding  a  presentation  system  to  allow  the  user  to  interact  more 
convenient!)  with  the  presenter  can  be  applied  to  the  other  presentation  system  components 
as  well,  e  g.,  to  the  present, ition  editor  and  recognizer. 

3.4  Shared  Screen  Space  (itd  Presentation  .Structure 

Ihis  section  examines  three  kinds  ol  sh.iring  that  can  (Kcur  in  presentations  systems.  In 
general,  sharing  iKcurs  when  some  part  of  a  presentation  system,  e.g..  a  ptirticular  part  of  the 
screen  space  or  a  particular  presentation,  simultaneously  fulfills  two  different  roles.  There 
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arc  iradcolTs  between  benefits  Df  compactness  and  costs  of  ambiguity. 

The  first  kind  of  sliai  ing  is  sharing  of  screen  space  belwcen  two  presentation  systems,  c.g., 
two  PPS  components  in  a  larger,  extetuled  presentation  system.  Presentations  that 
conceptually  belong  to  the  different  presentation  systems  are  often  intermingled  within  the 
Siime  space.  For  example,  in  the  Fimacs  Dircd  system  to  be  discussed  in  section  4.1,  a 
directory  listing  (a  presentation  in  one  PPS)  is  annotated  with  ''D"s,  which  arc  presentations 
of  plans  to  delete  files  and  which  belong  to  a  separate,  command-planning  PPS.  This  is 
contrasted  with  an  interface  that  has  two  such  presentation  systems  occupying  completely 
separate  areas  of  the  screen,  e.g.,  different  windows. 

The  second  kind  is  sharing  of  one  presentation  form  between  two  presentation  systems. 
The  shared  presentation  presents  two  different  pieces  of  information,  in  the  two  different 
application  data  base.s.  Consider,  for  example,  a  directory  listing.  An  interface  could  use  a 
directoi7  listing  for  more  than  just  presenting  a  directory:  it  could  also  use  it  as  a  means  of 
controlling  the  directory  listing  presenter.  The  user  could  trim  the  directory  listing  to 
inform  the  presenter  that  certain  files  should  not  be  included.  This  editing,  and  recognition 
of  it,  conceptually  occurs  in  a  separate  PPS.  The  directory  presentation  is  shared  between 
the  two  PPSs.  In  the  prc.scnter-control  PPS,  the  directory  listing  functions  as  a  presentation 
of  the  presenter’s  state. 

A  third  kind  is  sharing  of  one  presentation  between  two  presented  domain  objects  in  one 
PPS.  T  his  occurs  when  one  domain  object  is  presented  in  order  to  present  another  domain 
object.  A  typical  case  is  presentation  of  a  file's  creation-date  property  in  a  directory  listing. 
To  present  the  property,  the  value  of  that  property  is  presented,  namely,  the  particular  date. 
(And  the  process  may  continue:  to  present  the  month  property  of  the  il.ite.  the  particular 
month  is  presented.)  Thus,  a  single  presentation  form  (c.g.,  the  text  ”,1/4/83")  presents 
both  the  creation-date  property  and  the  particular  date  (3/4/83)  that  satisfies  dial  property. 

Sharing  of  screen  space  or  presentation  structure  can  provide  convenience  to  the  user 
because  it  resulLs  in  a  compact  prescnUition.  Sharing  can  achieve  what  might  be  called 
visual  locality,  two  presentations  of  related  domain  objects  are  located  near  each  other. 


Unn.)rtiin;ilcly,  sharing  can  also  lead  to  ainbiguiiy,  both  for  the  user  and  for  the 
impleniciUor.  I'he  user  may  not  know  which  ctliling  ("unctions  apply  to  presentatiotis 
shared  between  two  presentation  systems.  When  screen  space  is  shared,  the  user  may  not 
know  what  kind  of  recognition  to  c.\pcct  when  editing  the  dit'I'erent  presentations.  The 
implementation  must  also  keep  the  two  kinds  of  presentation  distinct,  so  that  the  proper 
editing  and  recognition  happen  to  each.  When  presentation  structure  is  shared,  the  user 
may  not  be  aware  how  presentation  editor  functions  arc  rccogni/ed  differently  by  the 
recognizors  in  the  two  presentation  systems.  1'hc  implementation  must  include  a  means  for 
selecting  the  recognizer  based  on  the  kind  of  editing  performed.  T  he  ambiguity  is  most 
severe  when  the  capabilities  of  the  presentation  editors  overlap.  The  choice  between  the 
two  recognizers  then  must  depend  on  context  or  user  choice. 


The  designer  should  identify  ambiguities  in  the  proposed  presentation  system,  and  decide 
which  ones  to  resolve.  Such  a  dcci.sion  must  take  into  account  the  prospective  users, 
conventions  in  the  style  of  the  interface,  the  particular  tasks  to  be  performed,  and  the 
applicaliOii  doiiitiii'i.  Sl'uii'iiig  miglit  be  eliiiiin^iteu.  Conventions  niigl'it  be  iiripi)^ei.i  on  tue 
kinds  of  sharing  and  the  methods  of  user  or  system  resolution. 


However,  regardless  of  the  outcome  of  the  decision,  the  designer  must  consider  that  there 
is  always  ambiguity  due  to  potential  sharing.  The  user  cannot  tell,  merely  by  viewing  the 
directory  listing,  whether  deleting  a  line  in  a  directory  listing,  for  example,  will  mean  don't 
present  that  file  (mtinipulating  the  presenter),  or  whether  it  will  mean  delete  the  file 
(manipulating  the  application  data  base).  Ambiguity  of  presentation  structure,  unlike 
ambiguity  of  shared  space,  is  an  inherent  possibility  of  the  view.  ResoKing  an  ambiguity  by 
eliminating  sharing  of  presentation  structure  does  not  make  the  presentation  appear 
flilTcrent.  (However,  another  presentation  may  be  introduced  nearby  to  perform  the 
eliminated  function.) 


Sharing  of  presentation  structure  within  a  I’PS,  such  as  arises  from  presenting  a  property 
by  presenting  its  value,  is  less  troublesome.  Its  ambiguity  can  be  resohed  by  the  recognizer, 
by  deciding  which  of  the  possibilities  is  appropriate  for  the  command  being  recognized. 


Kor  example,  if  user  edilitig  of  llie  erealion-dale  presenlalion  for  a  file  is  recogni/ed  as  a 
change  command,  then  only  die  crealion-daie  properly  I'lls  die  recognilion  --  one  cannot 
change  a  date,  (liy  changing  the  properly,  one  is  seiccling  a  dilTerent  date  to  be  the  value  of 
the  property.  The  original  date  value  is  left  unchanged.)  This  tcchnic|ue  is  olTcred  by  the 
PSBase  system,  and  so  rurlher  discicssion  of  this  technique  appears  in  section  5.1. 

3.5  Concluding  Remarks 

This  chapter  has  discussed  only  a  few  examples  of  how  presentation  systems  can  be 
constructed  by  hooking  primitive  presentation  systems  together.  There  are  many  more 
possibilities,  including  combining  these  extensions  and  creating  new  kinds  of  extensions 
using  similar  techniques.  (For  example,  a  system  might  offer  cascaded  presentation 
systems,  presenting  the  presentation  data  ba.se.)  In  modeling  actual  user  inlciTaces.  the  next 
chapter  illustrates  several  of  these  possibilities. 


Chapter  hour 

Describing  Presentation  Systems 


lliis  cluiptcr  ilhistnilos  the  use  of  the  presentation  system  model  as  a  descriptive  tool, 
fhe  model  provides  a  set  of  concepts  for  eminicrating  and  categorizing  basic  functions  and 
interactions  in  user  interfaces,  whether  or  not  those  interfaces  were  designed  with  this  model 
in  mind.  I  hc  behavior  of  four  dilTerent  user  interfaces  will  be  described  in  terms  of  the 
presentation  system  model.  In  each  example  the  focus  will  be  on  those  presentation  system 
mechanisms  that  play  the  most  imporUint  part  in  defining  the  style  of  interaction. 

A  secondary  aim  of  this  chapter  is  to  offer  support  for  claims  of  the  model's  generality, 
i.e.,  that  the  model  applies  to  a  wide  range  of  user  interfaces.  The  selection  of  user 
interfaces  dc.scribed  here  has  been  chosen  to  show  the  descriptive  process  by  example.  The 
reader  should  then  be  able  to  apply  this  process  to  other  interfaces  and  thereby  gain 
confidence  in  the  model's  generality. 

The  selection  thus  emphasizes  different  approaches  in  user  interface  techniques.  At  the 
same  time,  an  effort  was  made  to  choose  user  interfaces  that  exemplify  different  aspects  of 
user  interface  research  and  tlcvelopmcnt.  Part  of  that  effort  was  an  informal  poll  of  people 
involved  with  developing,  studying,  or  just  interested  in  user  interfaces.  They  were  asked  to 
name  three  "exemplary  user  interfaces.”  The  interfaces  used  in  this  chapter  all  have 
followers.  Ihere  were  many  favorites  and  strong  opinions,  but  nothing  near  a  consensus 
except  on  the  Xerox  Star  [Purvy,  Farrell  &  Klose  83]  [Smith.  Irby,  Kimball,  Verplank  & 
l  larslem  83]  and  Apple  Lisa  systems  [Lisa  84], 

PPSCalc  was  discussed  and  modeled  in  chapter  two.  Ikcaiise  PPSCalc  is  a  simple  version 
of  VisiCalc  [Ikil  82],  VisiCalc  has  already  been  treated  to  some  extent.  Actually  modeling 
VisiCalc  would  involve  describing  extensions  to  the  main  PPS.  Such  extensions  will  be 
suggested  by  those  used  in  modeling  the  user  interfaces  of  this  chapter.  Lo  avoid  this 


redundancy,  VisiCalc  or  other  sprcadslicct  programs  will  not  be  discussed  further. 


4.1  Kniac.s  Dired 

Dired  is  a  subsystcni  of  the  Emacs  editor  that  allows  the  user  to  perform  several  directory 
operations  by  manipulation  a  directory  listing.  The  version  of  Dired  described  here  is  the 
one  in  Emacs  on  the  ITS  operating  system  [SUillman  81]. 

Dired  is  an  e.x tended  prescnUition  system,  allowing  both  immediate  changes  to  the 
application  data  ba.se  (the  file  system  directory)  and  planned  operations.  Annotations  to  the 
directory’s  presentation  present  the  planned  operations.  Dired  has  two  other  component 
presentation  systems.  One  recognizes  presentation  editing  as  changing  the  state  of  the 
presenter.  The  other  confirms  the  user’s  planned  operations  by  offering  an  alternative 
presentation  of  the  planned  operations. 

Dired  Scenario.  The  following  scenario  will  illustrate  the  use  of  Dired.  After  the 
scenario,  the  presentation  system  model  of  Dired  will  be  discussed. 


The  user  invokes  Dired,  initially  viewing  the  full  directory  listing  shown  below: 


MC  NSR 


FREE 

BLOCKS 

^0=1GG6 

;yi  =  625  H\Z  = 

1163 

=1461  #14= 

1549  #16=1149 

0 

BABYL 

BUGS 

26 

+486 

4/02/84 

14:09:26 

(4/02/84) 

.MAIL. 

13 

BABYL 

INFO 

27 

+488 

8/31/83 

14:37:09 

( ll/lG/83) 

.MAIL. 

L 

FIXLIB 

209 

=  : 

=>  EMACS1;FIXLIB 

> 

(5/06/83) 

13 

MAIN! 

BABYL 

5 

+27 

2/18/84 

17:01:42 

(3/01/84) 

1 

QUEUE 

NOTES 

2 

+83 

3/10/84 

10:20:13 

(3/23/84) 

1 

TEST 

VALUES 

0 

+69 

1/17/84 

19:20:14 

(4/03/84) 

1 

TMSG 

2 

1 

+34  $ 

3/28/84 

11:03:39 

(4/03/84) 

1 

TMSG 

3 

1 

+20  ! 

4/03/84 

21:53:21 

(4/03/84) 

1 

TMSG 

4 

1 

+248  ! 

4/03/84 

21  :57:45 

(4/03/84) 

1 

TMSG 

5 

2 

+94  ! 

4/03/84 

22:14:15 

(4/03/84) 

1 

TMSG 

6 

2 

+86  1 

4/03/84 

23:34:36 

(4/03/84) 

L 

TS 

NSRMAC 

=  : 

=>  NSR:TSNSRM  > 

(2/24/84) 

15 

TSNSRM 

1320 

13 

+463 

8/19/83 

20:44:23 

(2/24/84) 

The 

user  wishes  to  restrict 

attention 

to  those  files  that  mi 

ght  plausibly 

be  deleted  or 

moved  to  a  secondary  disk  pack.  In  particular,  several  files  are  related  to  the  maintenance 
of  the  mail  reader  Babyl  and  should  definitely  not  be  considered  for  deletion.  Using  the 
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Kinacs  coiiimaiid  Delete  Malehing  lanes,  lines  eoiUaining  the  text  "IIABYI."  are  removed, 
t  his  does  not  tieletc  those  files  -  it  only  al'feeLs  the  view  the  user  has  of  the  direetory. 
resulting  in  the  trimmed  directory  listing  shown  below: 


MC  NSR 


FREF 

BLOCKS 

//0=1666 

#1  = 

G25 

=  1163  //15 

=  1461  /!i'14  = 

1549  #16=1149 

L 

FIXLIB 

209 

= 

=>  EMACSliEIXLIB 

> 

(5/06/83) 

1 

QUEUE 

NOTES 

2 

+03 

3/10/84 

10:20;  13 

(3/23/84) 

1 

TEST 

VALUES 

0 

+  69 

1/17/84 

19:20: 14 

(4/03/04) 

1 

TMSG 

2 

1 

+34 

$  3/20/04 

11:03:39 

(4/03/84) 

1 

TMSG 

3 

1 

+  20  ! 

.  4/03/84 

21:53:21 

(4/03/84) 

1 

TMSG 

4 

1 

+248  ! 

4/03/04 

21:57:45 

(4/03/84) 

1 

TMSG 

5 

2 

^94  ! 

4/03/04 

22:14:15 

(4/03/84) 

1 

TMSG 

6 

2 

+  86  ! 

4/03/84 

23:34:36 

(4/03/84) 

L 

TS 

NSRMAC 

= 

=  >  NSR; 

TSNSRM  > 

(2/24/84) 

15 

TSNSRM 

1320 

13 

+  463 

8/19/83 

20:44:23 

(2/24/84) 

Deciding  that  the  llle  named  "QUFZUE  NOT  tiS"  is  no  longer  needed,  the  user  moves  the 
Fanacs  cursor  to  that  line  in  the  directory  and  types  a  ”D”,  marking  that  File  for  deletion. 


The  file  marked  for  deletion  is  shown  by  annotating  that  line  in  the  directory  listing  with  a 
"D".  There  are  several  versions  of  the  "TMSG"  file,  tuid  using  the  "H"  (Delete  Help) 
command  i  Dired  to  piKirk  olu  vcrsiOiio  for  deletion.  The"! I"  coiVi  i  i  ui  i'l  u  5C  i't  c  Tci 1 1  y 

marks  all  but  the  two  most  recent  versions.  However,  in  this  case  the  version  "TMSG  2” 
has  a  property  protecting  it  from  automatic  deletions  or  migrations  to  tape  (indicated  by  the 


in  the  listing).  Dired  will  therefore  leave  that  version  alone.  The  residting  directory 
listing  is  shown  below: 


MC  NSR 


FREE 

BLOCKS 

#0=1666 

#1  =  1 

525  #13 

=1163  #15= 

=1461  #14= 

1549  #16=1149 

L 

FIXLIB 

209 

=  : 

=>  EMACS1;FIXLIB 

> 

(5/06/83) 

D 

1 

QUEUE 

NOTES 

2 

+83 

3/10/04 

10:20:13 

(3/23/84) 

1 

TEST 

VALUES 

0 

+69 

1/17/84 

19:20:14 

(4/03/84) 

1 

TMSG 

2 

1 

+34 

$  3/20/84 

11:03:39 

(4/03/84) 

D 

1 

TMSG 

3 

1 

+  20  ! 

4/03/04 

21:53:21 

(4/03/84) 

D 

1 

TMSG 

4 

1 

+248  ! 

4/03/84 

21:57:45 

(4/03/84) 

1 

TMSG 

5 

2 

+94  ! 

4/03/04 

22:14:15 

(4/03/84) 

1 

TMSG 

6 

2 

+86  ! 

4/03/84 

23:34:36 

(4/03/84) 

L 

TS 

NSRMAC 

=  : 

=>  NSR; 

TSNSRM  > 

(2/24/84) 

15 

TSNSRM 

1320 

13 

+  463 

8/19/83 

20:44:23 

(2/24/84) 

Next,  the  user  moves 

the 

file  named  "TliSF 

VAl.UKS" 

from  the  primary  to  the 

secondary  disk  pack  with  the  "S"  command,  changing  the  line 


» 


1  TEST  VALUES  0  +69  1/17/84  19:20:14  (4/03/84) 

to 

13  TEST  VALUES  0  +69  1/17/84  19:20:14  (4/03/84) 

The  leftmost  "1"  and  "13"  in  these  two  lines  indicate  the  disk  pack  numbers  (0  and  1  arc 
primary  packs,  13  is  the  secondary  pack).  The  "S"  command  takes  effect  immediately, 
moving  the  file  to  the  secondary  pack  when  the  "S"  is  typed.  In  this  respect,  the  "S" 
command  is  unlike  the  "D"  and  "H"  commands,  which  mark  the  files  for  /a/er  deletion. 


rhe  "$"  command  changes  the  property  protecting  against  automatic  deletion.  The  u.ser 
moves  the  F.macs  cursor  to  the  "  rMSG  6"  line  and  types  "$".  That  immediately  sets  that 
property  and  updates  the  display,  changing  the  line 

1  TM,SG  6  2  +86  !  4/03/84  23:34:36  (4/03/84) 

to 

1  TMSG  6  2  +86  1$  4/03/84  23:34:36  (4/03/84) 

The  full  directory  listing  now  looks  like: 


MC  NSR 


FREE 

BLOCKS 

#0=1666 

#1  =  1 

625  #13=1163  #15= 

=1461  #14= 

1549  #16=1149 

L 

FIXLI8 

209 

= 

=>  EMACS1:FIXLIB 

> 

(5/06/83) 

D 

1 

QUEUE 

NOTES 

2 

+83  3/10/84 

10:20:13 

(3/23/84) 

13 

TEST 

VALUES 

0 

+69  1/17/84 

19:20  :  14 

(4/03/84) 

1 

TMSG 

2 

1 

+34  $  3/28/84 

11:03:39 

(4/03/84) 

D 

1 

TMSG 

3 

1 

+20  !  4/03/84 

21:53:21 

(4/03/84) 

D 

1 

TMSG 

4 

1 

+240  !  4/03/84 

21:57:45 

(4/03/84) 

1 

TMSG 

5 

2 

+94  !  4/03/84 

22:14:15 

(4/03/84) 

1 

TMSG 

6 

2 

+86  !$  4/03/84 

23:34:36 

(4/03/84) 

L 

TS 

NSRMAC 

=  : 

=>  NSR;TSNSRM  > 

(2/24/84) 

15 

TSNSRM 

1320 

13 

+463  0/19/83 

20:44:23 

(2/24/84) 

The  user  types  a  "Q"  to  indicate  that  the  deletion  plan  is  complete,  and  is  olTered  the 
following  alternative  display  of  the  deletion  plan  for  confirmation: 

Deleting  the  following  files: 

QUEUE  NOTES  !  TMSG  3  1  TMSG  4 

Ok? 


The  connmialion  shows  only  the  files  to  be  deleted  and  st^mc  of  their  important 
properties.  For  instance,  "!"  indicates  that  a  file  has  not  yet  been  backed  up  on  tape.  In  this 
case,  that  is  all  right  for  "  TMSG  3"  and  "rMSG  4",  since  those  arc  not  the  most  recent 
versions  of  the  file.  (If  the  user  had  marked  the  most  recent  version  of  a  file  for  deletion,  a 
">"  would  indicate  that  fact.)  Typing  "YtiS"  causes  the  plan  to  be  executed  and  the  files  are 
thereby  deleted. 

Dircd  Presentation  Model.  Figure  4-1  shows  the  structure  of  the  extended  presentation 
system  model  of  Dired.  It  has  four  component  presentation  systems.  labeled  "Presenter 
Control,"  "Directory  Listing,"  "Deletion  Planning,"  and  "Confirmation." 

Dir-ciory  Listing  /’PS.  The  main  PPS  presents  the  directory  and  recognizes  the 
immediate  commands,  such  tis  "S"  (move  file  to  secondary  pack)  and  "$"  (change  property 
protecting  against  automatic  deletion).  The  presentation  data  base  PDBl  comprises  the  text 
that  makes  up  the  directory  listing.  A  line  of  text  is  a  composite  pre.sentation  presenting  a 
file  or  link;  the  text  within  the  line  presents  properties  of  the  file,  such  as  the  file's  name 
("QUI.UF  NOTES"),  creation  date  ("3/10/84  10:20:13")  and  last-reference  date 
("(3/23/84)").  Several  of  the.se  presentations  are  in  turn  composites  of  smaller 
presentations  (e.g.,  "3",  "23",  and  "84"  are  components  of  "3/23/84"). 

The  presentation  editor  PEI  offers  the  "S"  and  "$"  commands,  both  of  which  are 
references  to  the  current  file  presentation  within  the  directory,  as  well  as  Emacs  commands 
for  moving  the  cursor  and  scrolling  text.  Recognizer  R1  immediately  translates  the  "S" 
command  into  the  command  to  the  file  system  to  move  the  file.  Presenter  PI  then  updates 
the  directory  listing  to  show  the  "13"  presenting  the  disk  pack.  Similarly,  the  command 
is  translated  by  the  R1  into  the  file  system  command  to  change  the  file  property.  PI  then 
changes  the  directory  listing  to  show  the  "$"  prc.scnting  this  property. 

Presenter  Control  PPS.  The  PPS  at  the  top  of  the  figure  is  an  interface  to  the  presenter 
PI  of  the  directory  listing  PPS.  The  application  data  base  of  this  extension  is  the  state  of  PI 
describing  which  files  arc  to  be  listed,  fhe  presentation  data  base  of  the  extension,  PDI12.  is 
shared  with  the  directory  listing  PPS.  In  other  words,  the  s;nnc  presentation  data  btise  is 


involved  in  both  presentation  systems. 


I'he  cxlension’s  presentation  editor,  FK2.  however,  is  not  the  same.  It  does  share  bmacs 
cursor  movement  and  scrolling  commands,  however.  Ihc  primary  caliting  commands  for 
l•’K2  arc  those  Kmacs  commands  that  delete  lines,  such  as  the  Delete  Matching  Lines 
commatul  mentioned  in  the  scenario  above.  The  rccogni/.er  R2  translates  these  line 
deletions  into  changes  to  the  directory  presenter  PI.  informing  it  that  certain  lllcs  (those 
lllcs  whose  presentations  were  deleted)  are  no  longer  to  be  presented. 

Since  this  extension  shares  the  presentation  data  base  of  the  directory  listing  PPS,  P2  is  an 
implicit  presenter,  tied  to  PI  in  that  Pi's  output  (tlie  pre,sentation  data  base)  is  itself  a 
presentation  of  PI.  In  general,  the  output  of  a  process  can  serve  as  a  presentation  of  the 
state  of  that  process. 

Deletion  Planning  PPS.  The  third  PPS  is  an  extension  of  the  main  directory  listing  PPS 
using  the  technique  of  adding  a  data  base  of  planned  commands.  A  delete  command  is 
presented  by  an  annotation  to  the  directory  listing  presentation:  a  ”1)"  placed  at  the  left  of 
the  line  presenting  the  flic  to  be  deleted.  Again  there  is  a  close  relationship  between  the 
presentation  data  base  of  the  deletion  planning  PPS,  PDB3,  and  that  of  the  directory  listing 
PPS,  PDBl,  although  the  two  are  not  the  same  in  this  case.  They  share  some  of  the  same 
screen  space,  but  the  component  text  presentations  are  different. 

The  deletion  planning  PPS  is  a  representation  shift  presentation  system:  the  state  of  the 
prcsentiition  data  base  conveys  all  the  information  about  the  delete  commands.  The 
presentation  editor  PL3  contains  the  Dired  "D"  and  "H"  commands  discussed  in  the 
scenario,  as  well  as  a  wide  range  of  other  Lmacs  editing  commands,  fhe  user  can  use  "D" 
or  "H"  commands  to  create  the  annotation  presentations.  They  simply  inse.t  "D" 
annotations  on  file  presentation  lines.  Altcntatively,  the  user  can  use  any  Emacs  editing 
method  of  inserting  a  "D"  at  the  beginning  of  a  line,  and  that  "D"  will  be  recognized  tis  a 
delete  command. 

Confirmation  PPS.  I  he  prcsenUition  system  at  the  bottom  of  the  figure  is  an  extension  to 


the  deletion  planning  presentation  system.  The  job  of  the  confirmation  system  is  to  give  the 
user  a  different  presentation  of  the  planned  delete  commands,  and  rceogni/e  the  "do  it" 
signal  for  the  deletion  planning  commands.  When  the  user  types  "Q"  after  creating  the 
plan  of  deletions,  the  deletion  planning  PPS  is  suspended,  and  control  passes  to  the 
conUrmation  PPS.  (If  the  user  does  not  confirm  the  deletion  plan,  control  will  pass  back  to 
the  deletion  planning  PPS.)  I'he  planned  delete  commands  arc  presented  by  presenting  the 
files  to  be  deleted  --  their  names  and  those  properties  most  frequently  useful  for  checking 
the  plan. 

Unlike  the  other  presentation  data  bases,  PDB4  is  a  completely  separate  presentation  data 
base.  It  has  a  trivial  presentation  editor,  Pl£4,  which  allows  the  user  to  type  in  the 
confirmation  answer.  Recognizer  R4  watches  for  these  answers,  and  signals  "do  it"  if  the 
answer  is  "YES".  (Other  than  the  "do  it,"  R4  sends  no  commands  to  the  delete-commands 
application  data  base.) 

4.2  Zniacs 

Zmacs[Zmacs  84]  is  the  text  editor  for  the  MIT  Lisp  machine  [Weinreb,  Moon  & 
Stallnnui  83].  Zmacs  has  many  capabilities,  and  a  complete  ntodel  of  its  presentation  system 
behavior  would  be  very  large.  This  section  will  describe  the  major  presentation  systems 
aspects  and  sample  the  rest 

BufTcr  PPS  and  Screen  PPS.  Figure  4-2  shows  the  most  important  structure  of  the 
presentation  system  model  of  Zmacs.  The  PPS  labeled  "Buffer  PPS"  and  that  labeled 
"Screen  PPS"  model  the  primary  presentation.  In  the  buffer  PPS  the  application  data  base 
ADB  is  presented  as  text  in  the  buffer,  i.e.,  PDBl.  (Text  files  arc  treated  here  as  long-term 
storage  of  presentation  data  bases.  Therefore,  this  section  will  concentrate  only  on  the 
bulTer.)  I'he  application  data  base  can  be  of  many  forms  and  is  frequently  not  realized  as 
any  explicit  set  of  programs  or  information.  For  example,  when  PDBl  contains  English 
text,  the  application  data  base  would  comprise  language  constructs  (words,  sentences, 
paragraphs,  etc.)  and  the  subject  matter  they  discus,s.  These  things  do  not  exist  in  the 
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conipiitor  anywhere,  but  they  are  neverllieless  being  presented.  Wiien  the  text  is  a  l  isp 
pn)grain.  on  the  other  hand,  the  application  data  Ixuse  is  the  l  isp  machine’s  computational 
environment. 

The  screen  PI’S  cascades  with  the  biiri’er  PI’S,  further  presenting  the  buffer  as  the  text 
that  appears  on  the  screen.  Most  user  interfaces  can  be  modeled  with  this  extra  stage,  but 
often  the  operation  at  this  level  is  trivial.  For  Zmacs.  however,  it  is  useful  to  discuss  the 
screen  PPS,  as  certain  Zmacs  commands  depend  on  the  distinction  of  PDBl  (the  buffer)  and 
PDB2  (the  screen). 

The  btd'fer  contains  text  (a  large  amount  possible  -  much  more  than  fits  on  the  screen). 
It  has  an  associated  current  position  called  poinr,  user-typed  text  is  inserted  at  point,  for 
instance.  There  is  sometimes  another  position  called  the  mark,  luul  the  interval  between 
point  and  the  mark  is  called  the  region. 

Presenter  P2  presents  a  window  of  text  around  point,  i.e..  a  contiguous  section  of  PDBl 
text  thtii  will  fit  on  the  display  window.  Point  is  presented  by  the  cursor.  The  region  is 
highlighted  on  the  screen,  either  by  underlining  or  by  reverse  video.  This  choice  is  made  by 
a  user  option,  i.e.,  a  I’2  presenter  control.  In  addition  to  choosing  the  window  of  text  P2 
must  also  consider  w  hat  to  do  with  lines  of  text  that  are  too  wide  for  the  window.  In  Zmacs 
these  lines  are  wrapped,  so  that  they  continue  on  the  next  screen  line,  with  an  exclamation 
point  to  present  the  fact  that  wrapping  has  occurred. 

Buffer  PPS  commands.  To  a  large  degree,  the  operation  of  a  text  editor  concerns  only 
PFl  and  PDBl.  with  most  user  editing  going  unrccogni/cd  until  much  later.  Zmacs  is, 
however,  more  than  just  the  combination  of  PFl  and  PDBl  (and  the  screen  PPS)  -  there 
arc  several  commands  whose  behavior  involves  recogni/cr  ;uid  presenter  action. 

F^or  instance,  consider  the  Fill  Paragraph  command  to  PI,  which  edits  the  paragraph  of 
text  around  point  to  have  lines  that  achieve  a  good  fit  within  the  margins.  As  the  user  types 
and  edits  the  text  of  the  paragraph.  RTs  organizational  recognizer  determines  the  block  of 
text  presenting  the  paragraph,  creating  that  paragraph  in  ADB.  The  Fill  Paragraph 


coininancl  signals  Pi's  organi/alional  presenter  to  perfonn  the  niling,  updating  the 
presentation  data  base  to  present  the  mDR  paragraph  in  the  filled  style.  Kinally,  P2  updates 
PI)  112,  the  sereen,  and  the  user  sees  the  result. 

Similarly,  consider  the  Indent  For  Lisp  command,  which  indents  the  current  line  of  a 
l  isp  e.xprcssion  according  to  its  syntactic  structure.  Recognition  has  been  proceeding  (in 
cITeet)  as  the  user  edits,  constructing  and  editing  the  Lisp  object  in  the  Lisp  environment 
ADR.  Up  to  this  point.  Pi's  organ i/ational  presenter  has  followed  the  user  -  i.e.,  done 
nothing  to  change  the  text.  The  Indent  For  Lisp  command  signals  the  organizational 
presenter  to  update  the  presentation  according  to  the  presenter's  indenting  style.  P2  then 
updates  the  screen  to  reflect  the  PDBl  changes. 

'[  he  Mark  Thing  command  sets  the  region  around  some  presentation  at  point,  the  kind  of 
presentation  being  determined  by  exactly  where  point  is.  If  point  is  in  a  word  or  Lisp 
symbol  presentation,  that  presentation  is  marked.  If  point  is  at  the  start  of  a  Lisp 
expression,  the  whole  expression  presentation  is  marked.  Recognition  of  this  command 
translates  into  a  mark  of  the  object  in  the  ADB  followed  by  presenter  update.  The  PDBl 
region  is  set  to  present  tliat  selected  ADB  object.  'Lhis  illustrates  the  need  to  consider  more 
than  just  text  tis  presentation  forms  --  the  region,  and  also  point  and  mark  separately,  can 
present  information  in  the  application  data  base. 

Finally,  consider  the  Evaluate  Region  and  Evaluate  Into  Buffer  commands.  Evaluate 
Region  causes  the  Lisp  expression  recognized  from  the  region  text  (or  if  there  is  no  region, 
then  the  Lisp  definition  around  point)  to  be  evaluated  in  the  Lisp  computational 
environment.  The  value  is  presented  in  a  small  window  at  the  bottom  of  the  screen. 
Evaluate  Into  Buffer  takes  its  text  to  be  recognized  from  a  different  area  (a  minibiijfer,  to  be 
discussetl  below),  and  after  evaluation,  presents  the  resulting  Lisp  value  in  PDBl  as  text 

Screen  PPS  conunands.  Most  Zmacs  user  comniands  go  to  PEI,  the  presentation  editor 
for  the  buffer  PPS.  L.tinmands  to  the  screen  PPS  components  involve  the  screen 
appearatiec  as  opposed  to  the  underlying  buffer  text.  Such  commands  concern  mouse 
references,  window  scrolling,  window  reshaping,  and  any  text  commands  that  depend  on 


whether  lilies  are  wrapped.  (I  or  inslaiiec,  such  a  coniniand  iniglu  move  the  cursor  down 
one  screen  line.  nio\  ing  (brward  in  the  bulTer  text  line  to  a  point  presented  on  the  screen  as 
directly  below.)  Window  movement  and  reshaping  commands  go  to  the  presenter  P2. 

Consider  the  l’E2  mouse  command  to  move  point.  The  user  points  to  a  bulTcr  position 
presented  on  the  screen  and  clicks  a  mouse  button.  Kecogni/er  R2  translates  the  reference 
in  screen  coordinates  to  a  reference  to  the  position  within  lH)IU‘s  text,  the  position  which  is 
presented  by  the  referenced  screen  position,  and  a  command  to  move  point  to  that  position. 
Presenter  P2  then  updates  the  screen  so  that  the  cursor  presents  the  new  position  of  point. 

Consider  also  the  PP2  mouse  command  to  mark  the  thing  at  the  mouse  position.  The 
user  points  to  a  presentation,  e.g.,  a  word  or  lasp  expression,  and  clicks  a  mouse  button. 
Again  R1  must  translate  a  screen  coordinate  reference  into  a  buffer  text  position  reference 
and  a  command  to  move  point  to  that  position.  In  addition  the  reference  translation 
includes  a  mark-thing  command.  That  mark-thing  command  is  further  recogni/ed,  within 
the  buffer  PPS  by  Rl,  as  described  above.  Ilius.  the  mouse  command  to  mark  a  thing 
requires  action  by  PP2,  R2,  Rl,  PI,  and  P2. 

Command  Minibuffer  and  Completion.  The  lower  half  of  figure  4-2  shows  the  model  for 
the  Zmacs  e.x/ended  command  minibuffer,  by  which  Zmtics  commands  can  be  given  by 
name.  Many  Zmacs  commands  are  connected  to  keys,  so  that  they  may  be  invoked  by  a 
single  keystroke.  However,  all  commands  may  be  invoked  from  the  minibuffer,  relieving 
the  user  of  the  need  to  remember  infrequently  used  keys.  rhus.  the  minibulTer  offers  a 
presentation  system  to  the  Zmacs  commands.  (For  simplicity,  we  will  consider  only  PFl 
commands.) 

The  minibuffer  is  a  two-line  buffer  at  the  bottom  of  the  screen  and  is  edited  almost 
entirely  as  is  the  main  buffer;  i.e..  PF3  is  almost  a  duplicate  of  PFl,  PF3  does  have  .some 
additional  commands,  primarily  concerning  command  completion  [Zmacs  84],  As  the  user 
constructs  the  command  name,  the  command  name  recogni/er,  R3.  attempts  to  determine 
the  pos.sible  commands  that  have  the  user  text  as  a  partial  string.  3  he  user  can  signal  the 
command  presenter  P3  to  aid  in  constructing  the  commaiul  name  by  filling  in  more  of  the 
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name  --  as  nuieh  as  can  unambigLiously  he  completed.  (K.g.,  if  the  user  has  typed  "I.  Mo", 
ami  the  only  command  whose  fust  wool  starts  with  "I."  and  second  word  starts  with  "Mo" 
is  Lisp  Mode,  then  "1.  Mo"  can  he  completed  to  "Lisp  Mode",)  1  he  user  eauscs  the 
contmand  to  he  eseevtted  hy  typing  Return;  this  causes  R3  to  stgn.tl  the  "do  it." 

In  tidrlition.  the  user  can  invoke  a  command  that  lists  the  possible  completions  of  the  tc.xt 
eiMislrueled  so  far.  Lliis  eommtmd  triggers  the  presenter  P4  in  the  command  completion  list 
PPS.  It  creates  a  new  presentation  data  base  PDP4  on  the  screen,  a  wimlow  of  the 
completions.  4  he  command  minihidTer  PPS  and  the  command  completion  list  PPS  both 
interface  to  the  same  application  data  base  of  PLl  commands.  PL4  allows  the  user  to  select 
a  completion  from  PDB4  with  the  mouse.  That  reference  is  recognized  by  R4  as  choosing 
that  particular  PLl  contmand  and  signalling  the  "do  iL" 

Other  Presentation  Aspects  of  Zniacs.  This  section  will  briefly  discuss  two  of  the  many 
other  prcscitlation  and  interaction  mechanisms  iit  Zmacs.  Most  of  those  not  discussed  here 
are  very  similar  tt)  the  ones  th;it  are  discussed. 

Mode  l.ine.  One  of  the  constmit  features  of  the  Zmtics  screen  is  the  mode  line,  a  small 
one-line  window  near  the  bottom  of  the  screen  that  presents  important  information  about 
the  .state  of  Zniacs  and  the  buffer  of  te.\t  being  displayed. 

f-or  instance,  the  mode  line  presents  a  list  of  the  control  modes  that  affect  the  action  of 
presenter  PI.  recognizer  Kl.  and  some  of  the  connections  of  keystrokes  to  commands.  One 
of  these  is  the  major  mode,  which  describes  the  kind  of  application  data  btrse  information: 
tc,\t.  lisp  programs,  etc.  I  here  arc  also  a  set  of  minor  modes,  with  more  localized  effects;  an 
example  is  a  mode  causing  lines  to  be  continually  Lilletl  ;is  they  are  being  typed.  1  he  mode 
line's  text  presents  these  modes,  tiiul  thus  presents  the  states  of  PPS  components,  with  labels 
such  as  "  Lext"  and  "Fill".  1  he  mode  line  as  described  thus  far  wouki  be  an  example  of  a 
representation  shift  except  th;it  it  cannot  be  directly  edited.  (Lor  example,  one  cannot 
change  the  major  mode  by  editing  its  presentation  in  the  mode  line.) 

[  he  mode  line  also  contains  a  presentation  of  th.e  screen  PPS  presenter.  P2,  aiul  PDB2's 
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relation  to  PDBl.  Small  arrows  pointing  up  or  clown  can  appear  at  the  right  of  the  mode 
line.  An  upward-pointing  arrow,  for  example,  presents  the  fact  that  P2  has  chosen  a 
window  with  more  of  PDBl  above  it. 

Scroll  Bar.  The  scroll  bar  is  a  small  display  that  appears  inside  the  left  edge  of  the  Zmacs 
window  when  the  mouse  moves  to  that  edge.  (See  figure  4-,T)  I  he  scroll  bar  consists  of  a 
vertical  line  segment  juxtaposed  against  the  left  window  border.  The  line  segment,  by  its 
position  along  the  border  and  its  relative  size  compared  with  the  border,  shows  the  size  and 
position  of  the  PDB2  window  relative  to  the  size  of  PDBl.  In  figure  4-3  the  PDB2  window 
is  about  one  fourth  the  size  of  PDBl  and  is  at  about  the  two  thirds  position  in  PDBl. 

The  line  segment  presents  PDB2;  the  border  I'.iC  presents  PDBl.  By  presenting  PDB2 
and  its  relation  to  PDB2,  the  scroll  bar  is  presenting  the  state  of  the  presenter  P2.  (In 
general,  the  state  of  a  process  can  be  presented  by  presenting  the  state  of  its  inputs  and/or 
outputs.) 

The  user  can  interact  through  the  scroll  bar  using  the  mouse.  Por  instance,  the  PDB2 
window  can  be  scrolled  by  a  quarter  of  its  size  by  making  one  kind  of  mouse  reference  to  a 
position  a  quarter  of  the  way  down  the  line  segment  (PDB2  presentation).  Or,  the  PDB2 
window  can  be  repositioned  within  PDBl  by  pointing  to  the  relative  position  along  the 
border  (PDBl  presentation).  The  scroll  bar  thus  offers  a  simple  PPS  interface  to  the 
presenter  of  the  screen  PPS,  P2. 

4.3  Xerox  Star 

The  Xerox  Star[Purvy,  Farrell  &  Klose  8.3]  [Smith,  Irby.  Kimball,  Verplank  &  Harslem 
83]  and  the  Apple  Lisa  [Lisa  84]  systems  offer  an  interface  organized  around  the 
manipulation  of  icons  -  pictorial  presentations  of  commands  and  data.  1  he  two  systems  are 
similar  in  many  respects,  .so  only  the  Xcro.x  Star  will  be  discussed. 

Xerox  Star  Scenario.  The  Xerox  Star  models  the  user's  ciuironmcnt  after  an  ofllce 
desktop.  (The  desktop  is.  in  effect,  a  directory.)  Arranged  about  the  desktop  are  various 


Figure  4-3:  Zmacs  Scroll  Bar 


Rluays  do  right.  This  will  gratify 
sohe  people,  and  astonish  the  rest. 

-  Mark  Tuain 

1-ihen  angry,  count  ten  before  you 
speak;  if  uery  angry,  an  hundred. 

-  Thof'ias  Jefferson 

When  angry,  count  four; 
uhen  oery  angry,  suear. 

-  Mark  Tuain 

Nothing  so  needs  reforming 
as  other  people's  habits. 

-  Mark  Tuain 
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documents,  in-boxes,  out-boxes,  and  folders.  Ihcsc  are  depicted  on  the  screen  by  icons, 
small  pictures.  A  document  icon  looks  like  a  piece  of  paper  with  a  title  on  it.  An  in-box 
icon  looks  like  an  in  box,  holders  contain  documents,  and  their  icons  look  like  manila 
folders,  (holders  are.  in  effect,  sub  directories.)  h'igurc  4-4  shows  a  sample  desktop  display. 

Also  on  the  screen  are  icons  for  more  things  than  would  normally  appear  on  a  real  desk, 
such  as  printers  and  Hle-drawers.  f  ile-drawer  icons  look  like  small  file  cabinets  and  indicate 
directories  on  remote  llle  servers. 

Interaction  involves  a  mouse  a/id  command  keys.  The  user  jc/cm  .something,  such  as  a 
document  icon,  by  pointing  to  it  with  the  mouse  and  clicking  the  left  mouse  button.  The 
selected  icon  is  highlighted.  The  user  then  gives  a  command  that  affects  the  selected  icon. 
Special  keys  are  provided  for  several  commands. 

One  important  command  key  is  open.  It  causes  the  contents  of  the  selected  thing  to  be 
displayed.  For  example,  opening  a  ckKument  displays  the  text  of  that  document.  Opening 
a  folder  displays  the  documents  within  that  folder.  Figure  4-5  shows  a  display  after  the  user 
opens  the  folder  Backup. 

There  arc  four  universal  command  keys:  move,  copy,  delete,  and  properties.  These 
commands  can  be  applied  to  any  Xerox  Star  object.  In  its  simplest  usage  die  move 
command  allows  the  user  to  reorganize  the  visual  desktop.  The  user  selects  the  document 
icon  and  gives  the  move  command.  Then,  as  the  user  moves  the  mouse,  the  document  icon 
follows  it.  Clicking  again  releases  the  icon  from  the  mouse. 

Another  important  use  of  the  move  command  is  to  manipulate  the  document  itself,  not 
just  the  organization  of  the  visual  display.  The  document  is  printed  by  moving  the 
document  icon  to  a  printer  icon.  The  document  is  moved  into  a  folder  by  moving  its 
document  icon  into  the  display  of  the  opened  folder.  A  document  is  moved  to  a  directory 
on  a  remote  file  server  by  moving  the  diKumcnt  icon  to  the  nic-drawer  icon. 

Typing  the  properties  commaml  key  produces  a  property  sheet  for  die  selected  item. 


Figure  4-5:  Xerox  Star  --  Opened  Folder 


I  iguiv  4-6  shows  iho  pari  ol' the  desktop  tlisplaying  the  property  sheet  lor  the  dcx  iinient 
named  Chapicr  7.  I  he  property  sheet  is  a  table,  displaying  properties  such  as  the 
doenment’s  name,  creation  date  ("version  of;"),  and  whether  to  display  a  cover  shed  when 
the  tlocument  is  openeil,  (A  cover  sheet  contains  fields  that  help  in  mailing  the  document, 
such  as  from.  to.  subject,  and  an  accompanying  remark.) 

Hie  user  may  modil'y  the  name  and  shon-  cover  shed  properties.  Kditing  the  name 
property  is  the  way  one  rentimes  a  document. 

A  document  or  folder  is  deleted  by  selecting  its  icon  and  then  typing  the  delete  command 
key.  (Similarly,  a  selected  section  of  document  text  in  an  opened  document  is  deleted  with 
the  s;imc  ccrmmancl.)  Uecausc  deletioits  arc  currently  not  retractable.  Xerox  Star  requires 
confirmation  from  the  user.  A  one-line  message  is  displayed  at  tlie  top  of  the  screen, 
together  with  a  yes/no  choice.  I  he  user  confirms  the  deletion  by  choosing  "yes"  with  the 
mouse.  I  igure  4-7  shows  the  upper  part  of  the  screen  during  a  delete  of  die  Backup  folder. 

Xerox  Star  Presentation  iModcl.  F-igure  4-8  shows  the  presentation  model  for  ih.e  part  of 
die  Xerox  Star  system  discussed  in  die  previous  scenario.  Tlic  moilel  comprises  four  PPS 
components.  As  in  the  model  for  Zmacs,  a  window-display  PPS  ca.scades  with  the  primary 


Desktop  PBS.  The  desktop  PPS  is  the  primary  PPS.  The  applicaition  data  base  ADFi 
contains  documents,  folders,  remote  file  servers,  in-boxes.  out-bo\cs,  and  printers.  These 
are  presented  by  icons  and  windows  in  the  presentation  data  b;ise  PDIU  (the  picture  of  the 
desktop).  Windows  prc.scnt  domain  objecls.  such  ;is  documents,  by  presenting  their 
contents  or  properties. 

Icons  have  little  presentation  structure,  but  even  icons  are  not  primitive,  i.e.,  they  arc  not 
name  presentations.  Two  kinds  of  presentation  structure  occur.  Icons  present  the  name  of 
the  document,  printer,  etc.,  and  the  appearance  of  the  icon  presents  the  type  of  the  object, 
by  depicting  a  stylized  typical  example. 


Figure  4-6:  Xerox  Star  -  Property  Sheet 
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Figure  4-7:  Xerox  Su«r  --  Delete  Confirmation 


you  want  to  DELETE  that  object? 


Wiiulows  arc  composite  presentations  with  many  sub-presentations.  I  'okler  windows.  Tor 
e.xample,  present  the  collection  of  d(xnmenl.s  and  sub-folders  in  the  folder  by  presenting 
them  as  icons  within  the  window. 

Consider  the  move  command  discussed  in  the  scenario,  an  operation  provided  by  the 
present.ilion  editor  PHI.  The  move  may  go  unrecogni/ed,  merely  changing  the  position  of 
icons  on  the  desktop.  However,  when  a  dtK'umenl  icon  is  moved  ne,\t  to  a  printer  icon, 
recogni/,er  R1  translates  the  move  into  a.  prim  command.  When  a  document  icon  is  moved 
into  a  window  presenting  an  ojicncd  folder,  R1  translates  the  move  into  a  command  to 
move  the  document  into  that  folder.  In  other  words,  spatial  adjacency  to  a  printer  icon 
presents  the  fact  that  a  document  is  being  printed;  spatial  containment  within  a  folder 
window  presents  the  containment  of  a  document  within  a  folder.  The  user  can  create  these 
spatial  relations  using  PEI,  and  R1  implements  the  commands  to  create  those  presented 
conditions. 

'fhe  delete  command  in  the  scenario  refers  to  a  selected  document  icon.  Recognizer  R1 
translates  this  into  a  delete-document  command,  but  docs  not  immediately  send  it  to  the 
applictition  data  b;isc.  The  delete-con  11  miation  PPS  is  used  to  allow  the  user  to  first  confirm 
the  deletion. 

Dclcle-Confimiation  ITS.  fhe  application  data  base  of  the  delcie-confirmation  PPS 
contains  two  rcrogni/cr  control  commands;  a  confirmation  ("do  it")  and  an  abort.  These 
commands  arc  presented  in  P[)n2  by  prc.senting  the  delete  command  in  the  question  and  by 
presenting  the  choice  between  the  two  commands  ;is  a  yes/no  box. 

The  user  references  the  yes/no  box  with  the  mouse,  using  presentation  editor  PH2. 
Recognizer  R2  translates  this  into  the  conllrmation  or  abort  command  ;uid  sends  the 
command  to  Rl.  If  confirmed,  R1  proceeds  to  send  the  delete  command  to  ADB. 

WinJuw  PPS.  Some  text  and  graphical  objects  in  PDBl  arc  within  windows  for  opened 
documents,  property  sheets,  etc.  from  the.sc  PDBl  objects,  presenter  P.l  selects  those 
objects  that  will  appear  in  the  window.  These  visible  icons  and  text  arc  the  contents  of  the 


prescntalion  data  base  PDB3, 


Mouse  references  lo  text  or  icons  within  the  window  are  made  witli  presentation  editor 
PH3  and  translated  into  references  to  the  presentation  data  base  PDBl  by  recogni/er  R3. 
These  are  then  further  recogni/cd  by  R1  as  commands  to  the  application  data  base. 

P3-Control  PFS.  The  window  presetUer  P3  accepts  presenter  control  commands  for 
scrolling  the  window.  Scroll  commands  arc  presented  by  arrows  in  the  margin  of  the 
window,  i.e.,  in  presentation  data  b;ise  Pt3(f4.  by  presenter  P4.  The  user  can  point  to  those 
arrows  with  presentation  editor  PH4.  Recognizer  R4  translates  those  references  into 
selection  of  scroll  commands,  together  with  a  "do  it"  causing  them  to  be  sent  to  P3. 

4.4  Steamer 

Steamer  is  a  prototype  system  designed  to  help  train  operators  of  U.S,  Navy  steam 
propulsion  systems,  incorporating  color  graphics,  knowledge-based  instruction,  :utd 
comprehensive  simulation  models  [Stevens,  Roberts  &  Stead  83]  [Stevens  &  Roberts  83]. 
Only  the  user  interface  aspects  of  the  graphics  and  its  connected  simulation  model  will  be 
considered  here. 

Steamer  uses  a  simulation  model  chat  consists  of  about  eight  diousand  state  variables, 
together  with  updating  futictions,  which  are  processed  once  a  second.  (The  simulation 
proceeds  in  real-time.)  The  user  watches  an  animated  schematic  view  of  the  simulation. 
There  are  several  such  views,  one  of  which  is  shown  in  Hgure  4-9.  The  schematic  is 
continually  updated,  producing  an  animated  view  of  the  system.  Certain  elements  in  the 
system  can  be  made  to  fail  (e.g.,  a  valve  slicks  open),  to  provide  training  lor  emergencies. 

Ihe  user  controls  the  system  by  pointing  to  various  parts  of  the  schematic  with  a  mouse 
and  by  using  menus.  Pointing  to  a  valve  icon  changes  its  state,  opening  or  closing  it. 
Throttles  are  set  by  pointing  to  the  position  within  them  that  indicates  the  new  value.  Kluid 
levels  are  changed  by  pointing  to  a  new  level  position  within  Ihe  fluid  lank  icon.  In  addition 
lo  pointing,  another  console  displays  different  menus  of  operations  and  choices  f  r 


90 


controlling  the  siimilation  aiul  choosing  displays,  figure  4-10  shows  a  sanijile  display  of  the 
menu  console. 

In  what  follows,  two  kinds  of  users  will  he  mentioned,  the  student  and  'he  instructor. 
Both  use  SteaJiicr's  schematic  cililor.  The  instructor  uses  the  schematic  editor  to  buikl  the 
schematic  views  r)rthe  system.  1  he  student  uses  the  schematic  editor  to  build  controllers  for 
a  process. 

The  feedback  Minifab  [forbus  81]  is  an  e.xtension  to  Steamer  designed  to  teach  control 
system  concepts,  for  instance,  one  exercise  is  to  ensure  that  the  temperature  of  oil  in  a 
sump  remains  at  a  specified  value.  The  student  builds  a  controller  by  selecting  graphical 
icons  of  a  measurement  device,  comparator,  actuator,  etc.,  and  connecting  them  together  on 
the  screen.  Steamer  builds  the  underlying  simulation  for  this  device  and  connects  it  into  the 
main  simulation  model  so  that  the  student  can  study  the  resulting  operation. 

Steamer  Presentation  Model.  The  heart  of  the  Steamer  user  interface  is  the  continual 
schematic  view  of  the  state  of  the  simulation.  This  view  is  modeled  by  tlic  PPS  labeled 
"Simulation  Schematic  PPS"  in  (igure  4-11.  7 lie  application  data  base  AOBl  contains  the 
set  of  simulation  state  variables  and  various  functions  of  these  variables.  The  presentation 
data  base  PDBl  is  the  color  graphics  schematic. 

Steamer  schematic  presentations  arc  constructed  from  icons,  c.g.,  symbols  for  valves, 
gauges,  pipes,  etc.  f  igure  4-12  shows  a  .vample  of  these  icons,  riicsc  present  state  variables 
or  functions  of  state  variables,  f.ach  kind  of  icon  presenLs  information  in  a  particular  way. 
Valve  icons  are  green  to  present  an  open  valve,  red  to  present  a  closed  valve.  Dials  have 
indicators  that  point  to  the  presented  values.  Pipe  presentations  (rectangular  pathways 
between  other  icons)  use  color  map  technicpies  to  show  animated  fluid,  with  small  colored 
blocks  moving  through  (he  pipes.  The  apparent  .speed  of  movement  presents  the  speed  of 
the  fluid,  as  computed  from  state  variables.  I  he  kind  of  lluid  (e.g,,  steam,  water,  oil)  is 
presented  by  the  color  of  the  moving  blocks. 

I  he  schematic  presentation  is  updated  by  presenter  PI  after  each  c\  f  of  ihc  simulatii'iii. 
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Figure  4*1 1:  Steamer  Model 


Figure  4-12:  Sample  of  Steamer  Icons 


when  the  set  of  state  variables  is  consistent.  Thus  the  user  sees  an  animated  presentation  of 
the  ongoing  process.  This  is  a  different  situation  from  the  other  user  interfaces  discussed  in 
this  chapter. 

There  are  two  kinds  of  animation  in  this  presentation.  First  is  the  overall  schematic 
animation  just  mentioned,  produced  by  continually  updating  a  presentation  of  a  changing 
process.  1  he  other  kind  of  animation,  however,  is  an  explicit  graphics  technique  used  as  a 
presenuition  itself--  the  presentation  of  fluid  flow  within  pipes.  This  animation  is  produced 
by  graphics  routines  from  a  static  description  of  the  process,  i.c.,  computed  from  a  single, 
instantaneous  simulation  state.  (The  pipe  flow  animation  continues  even  when  tlie 
simulation  is  halted  -  just  as  other  information  about  that  single  state  is  still  visible,  such  as 
dial  readings  or  valve  colors.) 

Presentation  editor  PEI  lets  the  user  interact  in  the  simulation  schematic  PPS  by  mouse 
reference.s.  Recognizer  R1  interprets  these  references  in  many  ways,  depending  on  their 
positions  within  the  different  kinds  of  icons,  translating  the  references  into  changes  to  state 
variables. 

Presentation  editor  PEI  in  the  Feedback  MiniLab  also  lets  the  user  create,  move,  connect, 
and  edit  icons  for  the  process  controller.  Recognizer  Rl  translates  these  created  controller 
presentations  into  commands  to  create  the  simulation  for  tliat  controller  and  connect  it  to 
the  rest  of  the  Steamer  simulation. 

Steamer  Menus.  Steamer  has  many  menus,  occupying  a  second  screen.  Several  of  these 
are  modeled  in  figure  4-11.  I'he  select-schematic  menu  PPS  models  the  menu  tluit  lets  the 
user  select  which  schematic  to  view.  This  PPS  is  an  interface  to  the  presenter  PI,  with  an 
application  data  base  of  PI  commands  to  select  the  various  schematics.  Presentation  data 
base  PDB2  is  a  menu,  a  set  of  text  presentations,  each  naming  a  schematic.  Presentation 
editor  PE2  mcxiels  the  user's  selecting  a  menu  item  with  the  mouse.  Recognizer  R2  then 
translates  that  into  a  choice  of  the  presented  select-schematic  command  and  sends  it  to 
presenter  PI. 


I'hc  casually  ineiui  Pi’S  is  another  inlcrfacc  lo  Iho  main  applicalion  data  base  ADBl.  the 
sel  of  simulalion  variables.  Willi  this  menu.  Uic  student  or  instructor  chooses  a  casualty, 
recognized  as  a  command  to  change  some  set  of  variables  to  simulate  the  particular  device 
fail  lire. 

Creating  Views.  I  he  instructor  schematic-editing  PPS  enables  the  instructor  to  build  and 
alter  the  main  presenter  Pi's  schematic  views  of  the  simulation.  The  schematic  editing 
offered  by  presentation  editor  PF.4  is  similar  to  what  the  student  has  when  creating  a  process 
controller,  e.\cept  for  this  PPS  the  simulation  is  not  being  changed.  Instead,  the  style  of 
schematic  presentations  that  PI  builds  of  the  simulalion  is  changed  or  extended. 

The  PPS  labeled  "Tap  PPS"  extends  the  instructor's  interface  lo  the  recognizer,  R4,  of  the 
schematic  editing  PPS.  As  the  instructor  builds  a  schematic  presenUition  for  a  new  view,  R4 
must  be  able  to  determine  what  sitnulation  variables  or  functions  on  them  these  new  icons 
will  present.  (In  Steamer  temiinology,  R4  has  the  job  of  establishing  taps  from  the  icons  to 
tlie  state  variables.)  Presentation  data  biisc  PDB6  in  die  tap  PPS  offers  a  form  for  the 
instructor  to  fill  in,  e.g.,  specifying  a  expression  of  some  state  variables.  R4  combines  this 
information  with  mouse  references  to  the  new  icons  by  PF,4  to  establish  the  icon-simulation 
specification  for  the  PI  style. 

4.5  Summary  ofStruclural  Features 

This  section  summarizes  the  features  characterizing  the  structures  of  the  extended 
presentation  system  models  used  in  this  chapter  to  model  the  computational  behavior  of  the 
different  user  interfaces.  Although  the  interfaces  discussed  appear  very  different,  there  are 
some  strong  underlying  computational  similarities,  and  the  presentation  system  model 
highlights  these.  The  overall  appearance  lo  the  user,  the  use  of  icons  versus  menus,  etc.,  is 
certainly  very  important  to  the  success  of  the  interface.  However,  these  are  questions  of 
interface  style;  the  presentation  system  model  looks  below  the  style  to  identify  common 
components  and  behavior.  Ihc  success  of  the  presentation  system  base  concept,  as 
developed  in  chapter  five,  depends  on  this  commonality. 


The  primary  striicUiral  feature  to  be  discussed  is  the  way  in  which  one  PI’S  is  atUiched  to 
another.  There  were  several  kinds; 

PPS  to  a  Presenter.  In  Dired,  the  main  presentation  data  base,  the  directory  listing,  is 
also  used  as  a  presentation  of  the  directory  presenter's  state.  Kdiiing  the  directory  listing  is 
recognized  as  cx)nir()lling  the  presenter's  state.  Presenter  scroll  commands  arc  presented  by 
icons  in  Xerox  Star  and  the  scroll  bar  in  Zmacs.  Steatner  has  two  kinds  of  presenter 
interfaces:  a  menu  allows  selecting  scheniiitics,  and  schematics  can  be  edited  by  the 
instructor  to  change  the  schematic  style.  The  latter  capability  is  similar  to  Dired's  use  of  the 
directory  listing. 

PPS  with  Commands.  A  PPS  with  comnjands  to  a  component  in  some  other  PPS  allows 
planning  -  to  postpone  the  action  while  the  action  is  being  specified.  Dircd  includes  an 
annotation  interface  to  the  main  application  data  base  in  order  to  plan  delete  commands. 
The  Zmacs  minibufl'er  interface  allows  the  user  to  compose  a  presentation  editor  command. 
Star  and  Steamer  include  command  interfaces  to  recognizers,  the  delete  confirmation  PPS 
in  Star  and  Uie  tap  PPS  in  Steamer, 

Multiple  PPS  Interfaces.  An  application  data  base  can  be  presented  in  two  or  more 
separate  PPS  interfaces.  In  Dired,  the  deletion  planning  PPS  and  the  deletion  confirmation 
PPS  present  the  same  data  base  of  delete  commands.  In  Zmacs.  the  command  minibuffer 
PPS  and  command  completion  list  I^PS  both  present  the  same  data  base  of  presentation 
editor  commands.  In  Steamer,  the  main  (simulation  schematic)  PPS  and  the  casualty  menu 
PPS  both  offer  interfaces  to  the  main  (simulation)  application  data  base. 

Cascaded  PPS  Interfaces.  Zmacs  and  Xerox  Star  both  include  a  similar  cascade  of 
screcn/window  PPS  and  main  (bulTcr/desktop)  PPS.  Ihe  screcn/window  PPS  provides 
such  features  as  clipping,  scrolling,  line  wrapping,  and  mouse  reference.  Some  user 
commands  operate  within  the  scrccn/window  PPS,  others  within  the  main  PPS,  depending 
on  whether  they  depend  on  the  visual  aspect  within  the  window. 

Sharing.  Section  3.4  discussed  the  kinds  of  sharing  that  can  occur  within  presentation 


systems.  Two  imporumt  examples  have  occurred  in  this  chapter.  F-irst,  Dired  and  Stetuner 
include  a  presentation  shared  between  two  PPS  interfaces,  the  main  prescnuiiion  data  btise 
(directory  listing  or  schematic)  and  a  PPS  Interface  to  the  main  presenter.  IJy  editing  the 
directory  listing  or  schematic,  the  useraMitrols  the  main  presenter’s  prescniation  style. 

Second,  in  Dired.  screen  space  is  shared:  directory  annotations  arc  intermingled  with  the 
parts  of  the  directory  listing.  Somewhat  simpler,  hierarchical  space  sharing  occurs  in  the 
Xerox  Star,  where  windows  appear  within  the  overall  desktop  area,  and  such  things  as  scroll 
icons  control  the  window  presenter  appear  within  the  windows. 


Chapter  Mve 

PS  Base:  A  Presentation  System  Base 


A  presentation  system  base  is  a  collection  of  mechanisms  and  t(x>Is  for  building  user 
interfaces  whose  architecture  follows  the  structure  of  the  presentation  system  model.  A 
prototype,  called  PSBase,  has  been  implemented  on  the  MIT  Lisp  machine  [Weinreb,  Moon 
&  Stallman  83]  and  will  be  discussed  in  this  chapter.  With  a  presentation  system  base,  the 
job  of  building  good  user  interfaces  becomes  much  easier.  Chapter  six  illustrates  the  utility 
of  PSBase  by  discussing  the  implementation  of  an  interface  built  on  top  of  PSIhtse. 

In  cerUiin  respects  the  architecture  of  PSB<»sc  resembles  the  presentation  system  model 
proposed  in  chapters  two  and  three.  Some  of  the  PSBase  modules  support  particular  PPS 
components,  and  in  general,  domain-independent  and  style-independent  mechanisms  are 
isolated.  This  structure  in  turn  encourages  gix>d  modularity  in  the  user  interfaces 
constrvictcd.  Figure  5-1  shows  the  fundamental  support  of  PSBase  modules  for  PPS 
components.  Figure  5-2  shows  the  overall  structure  of  PSBase.  with  arrows  iiuliaiting  uses 
relations.  The  reason  the  PSBase  architecture  docs  not  exactly  resemble  the  PPS  model  (see 
figure  2-1  on  page  29)  is  due  to  the  different  goals  of  the  model  and  the  base.  1  he  PPS 
model  analyzes  the  activity  of  a  user  interface.  PSB;bc  is  structured  to  cmjdiasizc  the 
sharing  of  knowledge:  information  is  not  redundantly  rcprcscnicd.  Also,  figure  5-1  shows 
only  some  of  the  PSITise  support:  the  basic  style  packages  module  supports  the 
construction  of  combinations  of  PPS  components  and  PPS  extensions. 

Fach  PSBcise  module  will  be  discussed  in  a  section  below.  There  arc  three  layers  in  the 
structure:  The  data  base  nicchanisins  module  at  the  bottom  of  tlie  figure  is  (to  a  large 
extent)  a  general  support  package,  not  specific  to  user  interfaces.  The  four  middle-layer 
modules  represent  general  presentation-system  support,  i.e..  tools  and  mechanisms  used  to 
construct  various  interlace  styles.  'Hie  ba.sic  .style  packages  module  at  the  lop  of  the  figure 
comprises  specific  components  of  interface  styles  that  the  interface  builder  may  or  may  not 


Figure  5*1:  PSBase  Support  of  PPS  Components 


Figure  5-2:  Slruclurc  of  PSBcisc 


Data  Base:  Mccf/Aiv /sms 


chfKjsc  U)  include.  I'hosc  packiigcs,  however,  arc  indcpendenl  of  any  particular  application 
domain. 

5.1  Data  Ba.se  Mechanisms 

PSBase  includes  support  for  building  data  bases  structured  as  networks  of  objects.  Much 
of  this  support  is  provided  by  the  l.isp  machine's  flavor  system  for  object-oriented 
programming.  PSBase  imposes  certain  conventions,  provides  an  existing  (lavor  structure  for 
the  descriptions,  and  provides  tools  for  manipulating  and  extending  the  network  structure, 
■fhe  l  isp  machine  flavor  mechanism  allows  multiple  inherittmee  of  ckisses  of  objects 
(flavors).  PSBase  extends  this  slightly  to  allow  limited  inheritance  and  description  of 
properties  of  objects  (instance  variables  of  flavor  instances). 

The  basic  data  base  mechanism  is  used  for  building  application  data  b.'iscs  (descriptions  of 
files,  directories,  mtiil,  and  commands,  for  example)  and  the  presentation  data  base  (various 
kinds  of  presentations,  their  properties,  and  their  relationships).  An  important  point  is  that 
the  presentation  and  application  datii  bases  arc  linked  together,  so  that  in  elTect  they  arc 
both  part  of  a  large,  uniformly  structured  data  base.  Many  of  the  PSBase  mechanisms  rely 
strongly  on  the  f;ict  that  the  same  data  base  mechanism  is  used  throughout.  Because  of  the 
importance  of  the  data  base  mechanisms,  they  will  be  discussed  in  detail  in  this  section. 

One  example  of  the  benefits  of  having  a  unifomi  representation  tcchnic|uc  is  that  the 
presenter's  domain  collector  and  other  domain -dependent  modules  can  be  minimized  and 
more  presentation  mechanisms  can  be  shared,  fhe  interface  builder  can  experiment  and 
change  the  implementation  more  easily,  changing  the  presentation  styles  or  adding  new 
presentations,  for  cxtimplc.  Uniformity  facilitates  the  construction  of  presenters. 

This  research  did  not  attempt  to  build  a  state-of-the-art  knowledge  representation  system. 
However,  the  data  base  mechanisms  in  PSBase  arc  inspired  by  such  systems  (c.g.,  KL-One 
and  its  successors  NIKL  and  KL-Two [Brachman  78][Brachman  &  Schmol/e  85]  and 
Omega  [Attardi  &  Simi  81]  [Barber  82]),  and  a  full-scale  presentation  system  base  may  very 
well  benefit  from  such  a  system. 


An  important  capability  of  tlic  data  base  mechanism  is  allowing  the  description  of  classes 
of  objects  and  the  relationships  between  classes  --  particularly  spcciali/ation  and  the 
inheritance  of  properties  of  objects  of  a  class.  Kigure  5-3  shows  an  example,  part  of  an 
application  data  base  network  describing  files  and  directories.  I'lic  application  data  biise 
contains  both  chiss  descriptions  and  also  instances  them. 

fhe  style  of  the  figure  is  based  on  that  used  for  drawing  Kl.-Onc  networks.  Kllipses  show 
cla.ss  descriptions;  shaded  ellipses  show  instances  of  classes.  Double-stemmed  arrows  show 
the  containing  class.  Small  boxes  connected  to  ellipses  show  properties;  these  properties  are 
inherited  by  more  specialized  classes,  (hi  addition,  as  will  be  seen  later  in  this  chapter,  other 
mechanisms  in  effect  "hang  off'  of  particular  classes  of  the  data  base,  and  these  also 
undergo  a  sort  of  inheritance.) 

f  'or  example,  the  class  file  is  shown  by  the  ellipse  labeled  ’Tile"  ;  it  is  a  specialization  of 
the  class  (i.e.,  a  kind  oO  generalized  file,  which  in  turn  is  a  specialization  of  the  class 
operating  svste/n  obiect  and  domain  object.  A  file  link  is  also  a  kind  of  generalized  file.  The 
network  shows  that  generalized  files  have  several  properties:  directory,  pathname,  etc.  Files 
and  links  inherit  these  properties. 

Eiich  particular  file  in  the  application  data  base  would  be  represented  by  an  instance  of 
file.  One  such  insuuicc  is  shown.  Its  reference  date  properly  is  shown,  linking  that  file 
insLince  with  a  particular  instance  of  the  cUiss  date.  The  file  instance  also  has  several  other 
properties  (directory,  path,  etc.),  linking  the  file  instance  to  directory,  pathname,  etc., 
instances,  though  they  have  not  been  shown  in  this  figure. 

Single-stemmed  arrows  from  a  box  shows  die  value  of  that  property,  or  for  classes,  the 
type  of  such  a  value.  Some  properties  are  specified  as  having  a  list  of  values;  directories,  for 
instance,  have  a  property  whose  value  is  a  list  of  files.  A  list  property  is  shown  as  a  box  with 
a  circumscribed  circle.  (One  of  the  limitations  of  PSBtisc  is  that  these  type-restriction  links 
arc  not  fully  implemented  in  the  current  implementation.  I  hey  are  shown  here  to  better 
document  the  relationships  of  classes  when  instantiated.  However,  PSI3a.se  does  include  a 
simplified  type  restriction  mechanism  used  for  certain  parts  of  the  data  base.) 


PSIkLso  alsi)  olTcrs  a  riiclimeiitary  ability  to  classify  properties.  This  ability  is  not  reflected 
in  these  llgiires.  in  the  interest  of  clarity.  For  instance,  circles.  tc,\t.  and  other  presentations 
typically  have  properties  defining  their  positions,  fhe  description  mechanisms  allows  these 
properties  to  bo  labeled  as  defining  position.s.  One  example  of  the  benefit  of  such  a  scheme 
(Kcurs  in  the  implementation  of  the  presentation  editor  function  that  moves  presentations: 
the  function  can  e.xamine  the  description  of  the  presentation  to  find  its  position-defining 
properties  and  change  them,  without  any  knowledge  about  the  particular  kind  of 
presentation. 

Presentation  Data  Base.  PSBasc  provides  a  mechanism  for  building  the  presentation 
data  base.  This  includes  an  already-constaictcd  part  of  the  data  base  network  structure  that 
defines  several  elasscs  of  presentations,  inter-presentation  relationships,  and  the  properties 
diat  connect  the  presentation  data  base  with  the  application  data  base.  (As  already 
discussed,  they  are  not  really  separate  data  bases,  but  rather  different  parts  of  the  same, 
overall  data  base  network.)  Each  presentation  can  have  a  record  of  the  presented  data  base 
object  ai'id  litc  prcsciUation  style  used.  iViost  of  the  modules  in  PSCilm:  (piescuLeis, 
recognizers,  graphics  redisplay,  etc.)  depend  on  the  known  organization  of  tlic  presentation 
data  b;ise  and  on  the  fact  that  it  is  part  of  die  overall,  uniform  data  base  structure. 

Figure  5-4  shows  part  of  the  presentation  data  btise  and  its  relation  to  the  application  data 
base.  The  main  class  is  presentation.  All  presentations  have  a  property  called  presented 
domain  object,  which  records  the  domain  object  being  presented.  For  example,  text 
presentation  T/  (an  instance  of  die  text  presentation  class)  is  shown  presenting  the  file 
OZ:<NSK>QUEUE.NOTES.  This  is  recorded  by  T/’s  prescnted-domain-object  property 
linking  77  with  the  file  instance. 

Figure  5-5  illustrates  three  kinds  of  inter-presentation  relationships  supported  by  the 
presentation  data  base  network  structure.  First,  composite  presentations  may  be 
constructed;  these  have  a  property  whose  value  is  a  list  of  sub-presentations.  Second,  a 
connecting  arrow  Joins  two  presentations;  the  arrow's  end  positions  (xl,  yl,  x2.  y2)  arc 
derived  from  its  end  prc.sentations'  positions,  fliird,  two  presentatiotis  may  be  attached. 


C'oiinccling  arrows  cause  llicniselves  to  be  attached  to  their  cud  preseiUatioiis;  in  general, 
any  two  presentations  may  be  attached.  I'he  attachment  relationship  is  asymmetric  and  has 
the  Ibllow  ittg  nieaiiing;  />/  attached  to  p2  implies  that  p!  is  repositioned  or  deleted  whenever 
p2  is  reposiliotied  or  deleted,  respectively.  In  the  rigiire  connecting  arrow  CA!  is  shown 
cr)nnecting  Texll  and  Texl2.  If  Textl.  say.  is  moved.  CA!  will  have  its  end  positions 
rederived.  Ihe  arrow  will  be  redrawn,  and  the  .<rrow  will  remain  connected  to  the  two 
pieces  of  te.xt. 

The  important  fact  about  this  scheme  for  structuring  the  presentation  data  base  is  that  the 
general  data  base  mechanism  is  being  used,  rather  th;in  a  representation  tailored  to 
particular  kinds  of  pictures.  I  he  presentation  data  base  llts  wiiliin  an  overall  data  biise 
network  with  a  uniform  method  of  organization. 

[his  lias  four  implications.  First,  the  data  base  mechanisms  can  be  shared.  Second,  the 
data  base  mechanism  docs  not  limit  the  kinds  of  presentations  that  can  be  used  --  the 
network  can  be  e.xtcndcd  by  the  interface  builder  to  add  new  kinds.  T  hird,  ancillary 
information  about  the  presentation  can  be  recorded;  such  information  can  be  useful  to 
presenters,  rccogri/ers.  and  presentation  editing  commands  that  need  to  make  decisions 
about  the  presentation.  Fourth,  the  presentation  data  base  can  itself  be  treated  as  an 
application  data  b.-isc  --  it  can  be  presented. 

The  last  of  these  is  important  for  matching  the  stnicture  of  the  implementation  to  the 
structure  of  the  model.  One  kind  of  example  is  Uic  cascaded  presentation  systems  of  Zmacs 
and  Xerox  Star  as  modeled  in  chapter  four. 

Command  Description  Support.  PSBiisc  has  a  mechanism  for  describing  commands  in 
the  data  b.a.sc  and  connecting  these  descriptions  to  the  actual  Lisp  machine  functions.  User 
options  (Lisp  variables)  can  also  be  described,  and  command  dcKumcntation  can  refer  to 
these  variable  descriptions.  Variable  descriptions  themselves  can  have  associated 
documentation. 

The  cla.sscsof  description  involved  arc  shown  in  figure  5-6.  The  primary  kinds  of  objects 


arc  commands,  describing  Lisp  functions,  command  sets,  describing  groups  of  related 
functions,  and  command  applications,  describing  the  invocation  of  a  Lisp  functit)n  with  a  list 
of  arguments.  A  command  application  has  a  slate,  which  specifics  whether  the  function  hjis 
not  yet  been  invoked  on  these  arguments,  is  currently  being  executed,  or  has  completed. 
Functions  may  be  invoked  by  building  a  command  application  description  and  then,  using 
the  Lisp  machine's  flavor-system  message-passing,  sending  the  command  application  object 
an  execute  message. 

in  addition  to  the  properties  shown  in  the  figure,  commands  also  include  properties 
specifying  the  name,  documentation,  sub-commands,  variables  used,  and  the  verbs  that  may 
be  used  to  describe  the  command. 

Each  command  description  includes  a  list  of  parameter  descriptions,  which  must  match 
the  arguments  given  to  the  command  application.  The  command  application  object  checks 
its  arguments  for  validity  when  it  is  formed.  Each  command  parameter  description  includes 
properties  specifying  name,  documentation,  and  a  description  of  the  tvpe  of  the  argument 
required.  There  are  several  specializations  of  command  parameter  type,  one  for  each  kind  of 
argument  that  may  be  supplied  to  user  commands. 

For  example,  one  of  the  Lisp  functions  printing  files  Lakes  two  arguments:  a  file  and  a 
printer,  which  is  to  say  two  insutnees  in  the  application  data  base,  a  file  instance  and  a 
printer  insLance.  The  command  insUince  for  this  function  includes  a  list  of  two  parameter 
descriptions  that  describe  these  restrictions:  the  first  parameter  specifies  the  type  fde,  and 
the  second  parameter  specifies  the  type  printer.  To  invoke  this  function,  a  command 
application  insLance  is  created,  its  argument  list  containing  the  particular  file  and  printer 
instances.  As  the  command  application  is  formed,  the  arguments  are  automatically  checked 
against  the  parameter  types  for  validity.  The  command  application  is  then  sent  die  execute 
messiige.  causing  the  function  to  be  applied  to  the  arguments,  and  the  file  is  printed. 

Execution  Monitor.  The  command  description  mechanism  is  extended  by  automatic 
connections  to  the  l.isp  environment,  for  use  by  the  PSB:tse  execution  monitor.  When  a 
command  insutnee  is  created,  the  Lisp  function  it  corresponds  to  is  automatically  motlified 


s()  lhal  Ihc  execution  monitor  is  notified  when  the  function  is  invoked  and  when  it  returns. 
1  he  execution  monitor  maintains  a  stack  indicating  the  current  execution  state  in  terms  of 
the  described  priK'edurcs.  In  addition,  command  application  descri|nions  are  placed  on  the 
stack  while  they  execute. 

Ueferenee  Kesolution.  Presenters  and  recognizers  must  often  resolve  a  presentation 
reference  to  an  instance  in  the  data  base  of  a  particular  ty  pe  (or.  in  general,  to  an  instance 
that  stitisfies  some  predicate).  In  the  simple  case,  the  value  of  the  presentation's  presented 
domain  object  property  is  of  the  correct  type  attd  no  resolution  is  needed.  For  cases  when 
this  is  not  true,  PSfiasc  includes  a  mechanism  for  finding  a  related  data  biise  instance  that  is 
of  the  correct  type. 

An  example  will  serve  to  introduce  the  three  kinds  of  resolution  provided.  The  user 
invokes  a  command  that  requires  a  directory  as  one  of  its  arguments;  the  user  selects  a 
presentation  as  this  argument.  In  the  simple  case,  the  presented  domain  object  property 
links  the  presentation  to  a  directory,  luid  the  resolution  is  trivial  --  just  follow  the  presented 
domain  object  link.  Figure  5-7  illustrates  this  ettse  and  tltc  others  to  be  discussed.  The 
dotted  arrow  indicates  the  path  followed  by  the  resolution  mechanism  in  order  to  reach  the 
directory  instance.  (It  is  the  directory  instance  in  all  cases  that  will  be  returned  by  the 
resolution  mechanism.) 

The  first  (and  most  common)  kind  of  rescilution  applies  when  the  presented  domain 
object  is  a  property,  and  the  property's  value  is  of  the  desired  type.  Resolution  is  to  the 
property's  value.  In  the  case  illustrated  in  the  second  part  of  figure  5-7,  the  user  has  selected 
a  presenution  of  the  directory  property  of  a  file. 

1  he  second  kind  of  resolution  applies  only  to  certain  kinds  of  properties,  termed  essential 
properties.  These  are  properties  for  which  die  value  is,  in  some  sense,  equivalent  to  the 
object  owning  the  property  -  equivalent  in  terms  of  its  use  as  a  referent.  The  pathname 
property  of  a  file  is  cs.scntial  -  any  name  property  is.  (Specifying  which  properties  arc 
es.scntial  is  pan  of  the  task  of  defining  the  application  data  base  chess  network.)  For 
cs.scntial  properties,  the  re.solution  mechanism  walks  to  the  owning  object.  In  the  atse 


illusiratcd  in  the  third  part  of  figure  5-7,  the  user  has  selected  a  presentation  of  the  name  of 
the  directory. 

T  he  third  kind  of  rc.solution  walks  up  the  presentation  hierarchy,  from  tlic  referenced 
presetitation  to  the  composite  presentation  tliat  c-ontains  it.  looking  for  a  siitisfaclory 
presented  domain  object.  In  the  ca.se  illustrated  in  the  fourth  part  of  figure  5-7.  the  user  hits 
selected  a  presentation  that  is  a  part  of  a  directory  presentation,  but  which  docs  not  itself 
present  something  that  can  be  resolved  to  a  directory. 

5.2  Graphics  Redisplay 

This  section  discusses  the  next  PS  Base  module  shown  in  figure  5-2,  an  incremental 
graphics  redisplay  mechanism  that  hiis  the  responsibility  for  continually  displaying  the 
prescnuiiion  data  biisc.  The  graphics  redisplay  module  maintains  a  description  of  the  forms 
drawn  on  the  screen.  It  continually  compares  this  with  the  presentation  data  base 
description.  Those  presentations  whose  defining  properties  have  changed  are  redrawn  and 
the  screen  description  is  updated,  new  presentations  are  drawn,  and  deleted  ones  erased. 

Each  presentation  instance  htis  a  timestamp  that  is  automatically  set  whenever  any  change 
is  made  to  that  prcsenUiiion.  Graphics  redisplay  restricts  its  attention  to  those  presentations 
that  have  changed  since  the  last  graphics  redisplay.  Composite  presentations  are  marked 
changed  whenever  one  of  their  sub-presentations  is  changed.  Therefore,  die  search  for 
changed  prcsenUitions  is  substantially  reduced;  entire  composite  prescivlations  can  be 
skipped  by  a  single  check  of  the  composite  presentation’s  timestamp. 

Graphics  redisplay  connects  the  presentation  data  base  to  the  Lisp  machine's  graphics 
package  (extended  slightly  for  PSBasc).  The  defining  properties  of  the  forms  to  be  drawn  or 
erased  arc  passed  as  arguments  to  the  appropriate  drawing  procedures. 


5.3  Presentation  Pditor  Functiuns 

PSUasc  ori'crs  a  sot  of  proseiUalion  cililing  rnnclions  that  as  a  whole  can  bo  used  as  a 
general  presenialion  editor,  or  the  functions  can  be  selectively  combined  as  part  of  a  specific 
user  interface.  1  he  presentation  editor  functions  are  independent  of  the  data  base  domain, 
presenters,  recogni/ers,  and  their  styles,  (he  editor  funciions  also  have  a  hi.story-kceping 
mechanism  that  records  commands  used  and  the  preseiualions  affected.  This  history  is  used 
by  some  editor  functions  (e.g..  the  command  to  undo  a  previous  erase  command)  and  by 
other  PS  Base  motiules  if  needed  (e.g..  a  recognizer  may  need  to  inspect  the  editing  history). 

The  presentation  editor  is  a  combination  of  a  text  editor  and  a  diagram  editor.  I  he  user 
can  place  text  at  any  point  on  the  screen  and  u.se  Emacs-like  commands  to  edit  the  text. 
There  are  only  a  few  such  text-editing  commands  in  PSBase.  However,  this  is  due  to  the 
limited  nature  of  the  project,  and  not  to  any  inherent  limitations.  A  full-.scale  presentation 
system  base  following  this  approach  would  include  a  much  larger  editor  module.  The 
diagram-editing  capabilities  in  PSBase  include  the  following: 

*  Creating  lines  and  arrows  between  two  positions  or  between  two  presentations 

*  Creating  ellipses,  circles,  and  rectangles 

*  Creating  an  ellipse  or  rectangle  around  a  given  presentation,  computing  the  size 
and  position  from  the  presentation 

*  Moving  a  presentation  to  a  new  position 

*  Erasing  a  presentation  or  undoing  an  erase 

*  Attaching  or  unattaching  two  presentations  ruid  presenting  attachments  visually 

*  Aligning  one  prcsenUition  with  another,  by  center  or  edge  positions 


5.4  Presenter  Support 

1  his  section  discusses  three  kinds  of  presenter  support  provided  by  PSBase;  first,  a  data 
ba.se  mechanism  for  describing  certain  properties  of  presentation  styles,  second,  three 
general  semantie  presenters  that  arc  driven  by  these  style  descriptions,  and  third,  some 
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orgiulizaiional  presenters  that  may  be  ituiepcndcnily  combined  with  the  semantic  presenters 
in  order  to  specify  a  style’s  layout  method. 

Presentation  Style  Descriptions.  A  presenter  has  an  associated  style,  which  describes  how 
the  prescntalioi?  is  structured  and  related  to  tlie  presented  information.  I  hcre  arc  four  basic 
classes  of  style  descriptions  in  the  current  PSHtise  implementation: 

Primitive  presenuuion  styles  do  not  refer  to  other  presentation  styles,  nor  do  Uicy  describe 
the  structure  of  the  presentation.  Instead;  they  specify  a  procedure  that  creates  it  (a 
"canned"  presenter).  One  goal  of  PSH;isc  is  to  reduce  the  number  of  primitive  presentation 
styles  that  must  be  written,  as  they  require  considerably  more  effort  tlian  do  the  other  styles 
discussed  here. 

Graphical  presentation  styles  do  not  refer  to  other  styles  either,  but  do  include  a 
specification  of  the  prcsenuition  forms  and  their  properties.  These  properties  may  be 
computed  from  properties  of  the  presented  domain  object  and  from  properties  of  the 
composite  presentation  being  constructed. 

Sequence  presentation  styles  specify  how  to  present  sequences  of  objects  in  the 
application  data  base.  For  instance,  a  directory  contains  a  sequence  of  files,  along  with 
other  properties  of  tlic  directory,  such  as  its  name  and  protection.  Sequence  presentation 
styles  specify  a  presentation  style  to  use  for  the  element  presentations.  They  also  optionally 
may  specify  prefix,  infix,  and  suffix  presentations  to  separate  the  presentations  of  the 
elements  of  the  sequence. 

Template  presentation  styles  build  larger  presentation  styles  out  of  a  fixed  number  of 
smaller  ones,  interspersed  with  text  presentations  that  do  not  present  any  domain 
information,  but  merely  serve  as  the  template. 

Each  kind  of  style  description  also  specifics  a  style  name,  the  class  of  domain  object  (in 
the  data  base  network)  for  which  this  style  is  appropriate,  a  flag  specifying  whether  this  is 
the  default  style  for  that  class,  information  concerning  semantic  redisplay,  and  an 


organi/ntional  presctilcr.  Since  domain  object  classes  can  be  specialized,  styles  can  apply  to 
a  wide  variety  of  objects  or  to  just  a  specific  few.  One  can  think  of  presentation  styles  as 
being  attached  to  classes  in  the  data  base.  These  attachments  drive  the  prexess  of  selecting  a 
suitable  presentation  style. 

Tor  example.  PSRase  provides  a  very  general  presenter,  ctillcd  the  phrasal  presenter.  This 
presenter  produces  (in  most  cases)  noun  phrases  for  a  given  domain  object.  This  style 
description  for  this  pre.scnter  specifies  that  it  applies  to  the  class  domain  object,  i.e..  it  applies 
to  any  instance  in  the  data  base.  This  applicability  derives  from  the  fact  that  the  phrasal 
presenter  can  always  produce  something  --  at  least  something  of  the  form  "a"  followed  by 
the  name  of  the  domain  object  chiss,  e.g.,  "a  file".  Furthermore,  it  takes  advantage  of  the 
uniformity  of  the  description  mechanism  and  inspects  the  properties  of  tlie  object  to  see  if  it 
has  any  property  that  is  a  kind  of  name.  If  so,  it  uses  the  name,  e.g.,  "the  file 
0/,:<NSR>QUFUF..NOTES.r'.  I  hc  phrasal  presenter  will  be  more  fully  discussed  below. 

On  the  other  hand,  another  presentation  style  applies  to  the  specific  chiss  time  of  day. 
protlucing  text  prcsenUitions  such  as  "02:04:46". 

Ihe  presentation  style  mechanism  supports  two  major  operations,  finding  a  named 
prcscnttition  style  and  finding  the  most  specific  presentation  style  applicable  for  a  given 
instance  in  the  data  base.  'Typiciilly,  several  styles  have  a  matching  chiss.  i.e.,  attach  to 
clas.scs  to  which  the  instance  belongs.  The  one  with  the  most  specific  nuitching  class  is 
chosen.  (E.g.,  time  of  day  would  be  preferred  over  domain  object  if  both  match.)  If  there  are 
two  or  more  styles  with  the  same,  most-specific  class,  the  default  is  chosen.  Styles  that  arc 
not  defaults  arc  invoked  specifically  by  ntunc.  In  a  larger  presentation  system  base  the 
comparison  could  be  more  involved,  taking  into  account  specific  properties  of  the  domain 
object  to  be  presented. 

Style-Driven  Semantic  Presenters.  PSBtise  olTcrs  three  semantic  presenters  whose 
behavior  is  determined  by  the  kinds  of  style  descriptions  described  above.  It  also  provides  a 
semantic  redisplay  mechanism  that  periodically  invokes  the  presenters  so  that  they  update 
existing  presentations.  Examples  of  the  three  major  kinds  of  style  descriptions  svill  be  used 


to  discuss  ilic  action  of  their  assixiatcd  presenters. 


The  first  example  is  a  simple  clock  presentation.  The  presented  domain  object  is  the 
current  time  of  day  insUmce  in  the  ap|ilication  data  b;ise.  Here,  the  presentation  is  a 
composite  of  two  siib-piesentations.  a  circle  (the  face  of  the  clock)  and  a  vector  (the  hour 
hand).  In  this  simple  clock  there  is  no  minute  hand  and  there  arc  no  text  labels  on  the  face. 
The  following  is  w'nal  the  interface  builder  would  write  to  construct  this  presentation  style 
(the  small  function  an^le-frotn-houn- and- minutes,  which  performs  the  simple  trigonometric 
calculations,  would  also  have  to  be  written): 

(dof-araphics-presentat  ion-style  CLOCK  TIME-OF-DAY  nil  t  120 
((NIL 

(circle-presentation 

:x  ( rel at i ve-to-parent-x  25) 

:y  ( rel ati ve-to-parent-y  25) 

:radius  25)) 

(; HOURS 

(vector -presentation 
:length  14 

:angle  (angle-f rom-hours-and-minutes 

(seiiu  p l  eseti led-tioiiia  i n-ub j ec t  ’:liours) 

(send  presented-doma  in-object  ':minutes)) 

;xl  (relative-to-parent-x  25) 

:yl  ( rel ati ve-to-parent-y  25))))) 

The  first  line  specifies  five  general  parameters:  the  style  name,  the  applicable  domain 
object  cla.ss,  a  flag  specifying  whether  this  is  the  default  style  for  that  class  {nil  here 
indicating  that  it  is  not  the  default),  and  two  parameters  for  semantic  redisplay.  The  first  of 
tile  two,  t,  is  a  flag  specifying  that  this  is  an  active  presentation  and  therefore  should  be 
ujidated  periodically.  I'hc  second,  120,  specifies  how  often  it  should  be  updated,  every  120 
seconds,  (j  his  updating  will  be  discussed  below.) 


Next  is  a  list  of  presentation  specifications.  The  first  one  specifics  the  circle.  The  nil 
indicates  that  the  circle  docs  not  present  any  domain  information  Then  comes  a  Lisp 
property  list,  (circle-presentation  ...),  specifying  that  this  presentation  is  a  circle  and 
specifying  its  properties.  For  instance,  die  first  property  .specified  is  the  x  coordinate  of  the 
circle's  center,  its  value  is  given  by  a  form  to  evaluate,  which  relates  the  circle's  position  to 
the  composite's  position  (which  generally  is  its  upper-left  comer). 


Next  is  the  specification  of  the  hour-hand  vector.  The  first  item  gives  tlic  property  this 
presentation  presents,  namely,  tlic  hours  property.  The  property  list  for  the  vector  is  similar 
to  the  one  for  the  circle,  except  that  it  Ik»s  a  more  complicated  form  to  specify  the  angle.  In 
particular,  it  has  two  mcssage-pa.ssing  forms  that  access  properties  of  the  presented  domain 
object.  (The  symbol  presenled-domain-ohject  will  be  bound  to  the  composite  presentation's 
presented  domain  object.)  The  first,  for  example,  (send  prescnlcd-damuin-objccl  ':hours), 
retrieves  the  value  of  the  hours  property  of  the  presented  lime  of  day  object. 


The  following  is  what  the  interface  builder  would  write  to  create  a  presentation  style, 
named  set-notation,  for  presentitig  instances  of  the  object-sequence  da^: 

(def-sequence-presentat ion-styl e  SET-NOTATION  OBJECT-SEQUENCE 

nil  nil  nil 

It  ^  II  II  II  ti  ^  II 

just-name 
: horizon  tal -layout 
; border-box) 

An  object-sequence  has  an  elements  property  containing  a  list  of  objects.  For  extimple,  if 
this  were  a  list  or  objects  with  the  names  (JNL,  i  t'VU,  and  I  tllil.k,  the  sequence  would  be 
prc.scntcd  in  this  style  as 


{ONE,  TWO.  THREE} 


I  he  first  five  arguments  are  the  same  as  for  the  graphical  presentation  style.  (In  this  case, 
the  last  two  nik  indicate  that  the  style  is  not  active,  i.e..  it  will  not  be  periodically  updated.) 

Ihc  third  line  of  the  definition  specifies  that  there  will  be  prefix  ("{"),  infix  (",  "),  and 
suffix  ("}")  text  presentations.  Ihc  fourth  line,  just-name,  names  the  style  to  use  for 
pre.senting  the  elemeiiLs.  'Ihe  fifth  line,  : horizontal-layout,  names  the  organizational 
presenter  to  use.  so  that  in  this  case  the  clement  presentations  will  be  laid  out  horizontally 
(with  the  infix  presentations  interspersed).  The  last  line,  .border-box.  specifies  that  a 
rectangle  should  be  created,  fitting  around  the  presentation. 


riie  following  is  an  example  of  the  la.st  of  the  three  style  descriptions,  a  template  style  for 


presenting  objects  of  the  class  iime\ 


( def- tempt ate-presentat ion-styl e  DEfAULT-TIME  TIME  t 
({:dale  default-date) 

( :  t  irne-of-day  defaul  t-time-of-day) ) 

; hori zontal -1 ayout) 

The  presenter  constructed  produces  composite  presentations  tliat  ltK)k  like 
"04/15/84  14:22:65".  The  name  of  the  presentation  style  is  default- lime.  'I4ie  t  after  the 
name  indicates  tliat  this  is  the  default  style  for  class  lime. 

The  next  three  linos  specify  the  domain  collector  and  semantic  presenter,  building  the 
template  and  specifying  the  sub-presentations'  presenters.  The  domain  collector  is 
described  by  naming  tlte  properties  of  the  ///w object  whose  values  should  be  collected.  (In 
more  complicated  presenter  specifications,  this  can  be  a  list  of  properties,  "walking"  from 
one  domain  object  to  another,  starling  from  the  object  being  presented.) 

The  first  specification,  ('dote  defciult-daie),  causes  th.e  date  property  of  the  time  object  to 
be  presented  as  the  first  sub-presentation,  using  lhchly\c  default  date. 

The  second  specification  is  a  text  string  containing  a  single  space.  This  causes  the 
composite  presentation  to  contain  that  text  as  a  amstani  sub-presentation.  (I.c.,  it  docs  not 
present  any  domain  object  --  it  is  just  part  of  the  template.) 

The  third  specification,  (:iime-of-day  default-time-of-day).  causes  the  time  of  day  property 
to  be  presented  as  the  third  sub-presentation,  using  the  style  default  time  of  day. 

The  last  form  specifics  the  organizational  presenter,  namely  horizontal  layout.  This  takes 
tlte  prescnUition  structure  created  and  positions  the  three  sub-presentations  within  the 
composite  presentation,  juxtaposed  horizonUtlly. 

The  template  below  illustrates  the  use  of  the  property-walking  capability  tliat  am  be  used 
in  presentation  styles.  The  examples  given  previously  have  all  specified  a  direct  property  of 
the  presented  domain  object,  c.g.,  tlie  hours  of  the  lime,  or  the  elements  of  the  object- 


sequence.  However,  in  genenil  il  is  necess;iry  to  specify  a  property  patlu  a  list  of  piopci  lics 
U)  follow,  starting  front  the  presenlctl  ciontain  object. 

Heiv..  a  presenter  is  created  for  the  class  user-at-host.  and  the  style  is  named 
RI'C7J3- User- At- Host.  ("RI  C73-V'  is  the  name  of  a  network  prottKol.  which  includes  this 
format  for  specifyittg  recipients.)  This  produces  a  form  of  electronic  mail  address,  such  as: 
"Norman  S.  Rafferty  <NSR  at  Mi  r-OZ>".  Figure  5-8  shows  a  stimple  section  of  the  data 
base  network. 

( def- tempi ate-presen tat ion-s tyl e  USER-AT-HOST 

RFC733-USER-AT-H0ST 

nil 

(((;user  rpersonal -name)  default-name) 

M  ^  M 

( : sel f  s impl e-atword-user-at-host) 

">") 

: hori zontal -layout) 

I  he  specirication  ((.  user  .personal-name)  default-name)  tells  the  domain  collector  to  walk 
from  the  user  at  host  object  to  its  user  and  frotn  there  to  the  user's  personal  tiantc.  The 
result  is  presented  in  the  default  name  style;  for  the  example  in  the  figure,  it  is  the  string 
"Norman  S.  Rafferty",  The  .-sc// "property"  in  the  second  domain  collector  specification 
means  that  the  user  at  host  itself  is  to  be  presented.  raUicr  than  one  of  its  properties.  Thus, 
the  composite  presenuition,  which  presents  the  user  at  host,  will  have  a  sub-presentation  that 
also  presents  that  user  at  host,  though  in  a  simpler  style;  "NSR  at  MIT-OZ". 

Organiz^itional  Presenters.  PSRase  provides  four  general  organizational  presenters,  and 
these  may  be  combined  with  any  of  the  semantic  presenters  by  tlie  style  description.  Each 
orgiuiizational  presenter  positions  the  sub-presentations  of  a  composite  presentation 
according  to  a  specific  layout  method. 

The  fiRt  h.as  already  been  mentioned  above:  the  horizontal  organizational  presenter 
positions  the  sub-presentations  in  a  horizontal  line,  each  presentation  juxtaposed  against  the 
right  edge  of  the  previous  one.  This  org,iniz.ational  presenter,  as  well  tis  tlie  others,  takes 
advanUige  of  a  facility  provided  by  the  presenuition  data  b;ise  mechanism:  each 
presenuition  can  be  asked  for  its  extent,  a  specification  of  the  upper-left  and  lower-right 


Figure  5*8:  Result  of  a  Presentation  Style 


comers  of  a  rcciangle  llial  would  enclose  die  preseiualion.  In  addilion.  die  presontalion 
editor  niecliatiism  offers  a  general  facility  for  moving  presentations.  Using  these 
capabilities,  the  organi/alional  presenter  does  not  need  to  consider  the  particular  kind  of 
presentation;  the  presentations  are  moved  so  that  their  extent  boxes  are  juxtaposeil.  Note 
that  the  extent  box  technique  works  ;is  well  for  sub-presentations  which  arc  themselves 
composites  of  further  sub-presentations:  the  entire  composite  has  an  extent  computed  from 
those  of  its  sub-presentations. 

Similar  to  the  horizontal  layout  presenter  is  the  vertical  layout  presenter.  It  juxtaposes 
sub-presenUitions  vertically,  again  using  the  extent  boxes  ;is  a  guide. 

The  third  organizational  |iresenter  uses  a  tabular  layout  method.  The  composite 
presentation  is  tissumcd  to  have  sub-presentations  which  will  be  the  rows  of  a  table.  These 
row  presentations  will  be  laid  out  vertically.  Furdierniore,  each  row  presentation  is  itself  a 
composite  (in  general),  whose  sub-presentations  are  the  elements  of  the  row.  These  element 
preseiilations  arc  positioned  so  that  those  presenting  the  stime  kind  of  property  are  aliened 
under  ctich  other.  For  example,  in  a  directory  listing,  those  presentations  presenting  file- 
length  properties  appear  aligned  under  each  other. 

The  fourth  organizational  presenter  is  a  paragraph  filler,  positioning  the  sub- 
presentations  (generally  single-word  text  presentations)  within  a  rectangular  area. 

The  PSBasc  graphics  prcsenhition  style  descriptions  do  not  use  standard  organizational 
presenters.  Instead,  the  styles  define  their  own  layout  in  die  style  description  itself  by 
explicitly  positioning  the  component  presentations. 

Semantic  Redisplay.  Faclt  presentation  style  specifics  whether  presentations  created  in 
that  style  w  ill  be  active,  i.c..  whetlier  it  is  to  be  periodically  updated,  and  if  so.  how  often  it  is 
to  be  updated.  Thus,  for  example.  <ui  active  sequence  presentation  will  be  updated  to  reflect 
changes  in  the  elements  or  in  the  order  of  the  elements  of  the  presented  sequence.  Or.  for 
the  clock  example  given  above,  the  properties  of  the  vector  presenialuin  (the  hour  hand) 
will  be  recomputed  from  the  presented  current-time-of-day  object. 


fiilch  time  ail  active  presentation  is  crcatetl.  a  semantic  redisplay  task  is  created  for  it  and 
added  to  a  list  of  all  ciirieiU  semantic  redisplay  tasks,  fliich  task  specifies  the  presentation, 
its  presenlalion  style,  and  the  next  lime  that  the  presentation  should  be  updated. 

A  background  prcKcss  manages  these  semantic  redisplay  tasks.  When  a  task's  semantic 
redisplay  lime  h;us  arrived,  the  presenter  for  its  presentation  style  is  invoked  on  the 
prescnuition.  This  invcxalion  is  similar  to.  but  slightly  different  from,  that  for  creating  the 
presentation  in  the  first  place.  Here,  cmphiisis  is  on  retaining  presentations  that  can  be 
rc-used  and  avoiding  computation  for  presentations  that  do  not  present  anything.  After 
updating  the  presentation,  the  presentation  style's  organizational  presenter  is  invoked  again 
to  adjust  the  presentation's  layout 

5.5  Recognizer  Support 

PSBase  provides  two  kinds  of  support  for  recognizer  control:  F  irst  is  a  mechanism  that 
records  the  presentations  on  which  a  particular  recognition  depends.  The  dependency 
mechanism  allows  some  recognition  to  be  retracted  if  changes  occur  in  the  presentations 
that  recognition  was  based  upon.  Second  is  a  recognizer-invocation  mechanism. 

PSBiise  divides  recognizers  into  three  kinds,  differing  in  how  and  when  they  are  invoked. 
Continual  recognizers  have  the  effect  of  acting  continually  as  the  user  gives  commands. 
General  recognizers  arc  invoked  on  demand,  by  particular  commands.  Invocation  of  general 
recognizers  is  slower  than  for  continual  recognizers,  and  the  invocation  involves 
consideration  of  a  larger  portion  of  the  prescnuition  data  base.  PSBase  offers  two 
invocation  mechanisms,  one  for  continual  and  one  for  general  recognizers.  The  remaining 
recognizers  arc  invoked  specifically  by  other  reaigriizcrs,  to  perform  particular  sub-tasks  in 
tlie  recognition  process. 

Recognition  Dependencies.  Pach  recognition  depends  on  a  set  of  presentations.  For 
example,  section  4.1  described  the  F.niacs  Dired  style  of  annotations  to  a  directory  listing: 
the  user  places  a  "D"  by  files  to  mark  them  for  later  deletion.  Recognition  of  a  "D"  (as  a 
plan  to  delete  a  particular  file)  depends  on  two  prescnUitions:  the  "D"  and  the  file 


prcscntalion.  If  ihc  user  moves  lliat  "D"  to  a  different  line,  however,  its  original  recognition 
must  be  retracted  and  new  recognition  performed  --  it  now  presents  a  plan  to  delete  a 
dilTerent  file. 

F'he  PSBase  recognition  dependency  mechanism  allows  recognizers  to  record  the 
presentations  on  which  they  depended,  together  with  the  actions  necessary  to  retract  that 
recognition.  Recognizers  specify  this  information  iis  they  build  the  application  data  ba.se 
commands. 

Invocation  of  Continual  Recognizers.  The  interface  builder  specifies  a  list  of  continual 
recognizers.  Each  is  invoked  immediately  after  each  keystroke  or  mouse  command. 

F.;ich  continual  recognizer  has  two  phases.  First,  it  quickly  decides  whether  it  is  in  fact 
applicable  to  the  command  that  the  user  just  gave.  Second,  if  applicable,  it  triggers  and 
performs  whatever  recognition  is  necessary. 

The  recognizer  has  access  to  the  presentation  editing  histoi^  entry  for  the  command  just 
completed.  It  also  has  access  to  tlic  list  of  recognizers  triggered  so  far.  if  any.  TIte  latter 
allows  the  recognizer  to  trigger  dependent  on  whether  or  not  others  did.  The  presentation 
editing  history  entry  specifies  what  kind  of  editing  function  wtis  perfoiincd  and  which 
presentations  were  affected  by  it.  This  itiformation  allows  the  recognizer  to  quickly 
determine  whether  it  is  applicable,  without  performing  a  .search  of  the  presentation  data 
base.  If  the  recognizer  triggers,  it  too  creates  an  entry  in  the  presentation  editing  history, 
specifying  that  a  recognition  was  performed,  its  kind,  and  tlie  presentations  it  affected. 

Currently,  the  mechanism  for  invoking  continual  recognizers  does  not  use  the  recognition 
dependency  mechanism,  because  of  efficiency  reasons  and  because  the  continual 
recognizers  do  not  in  general  benefit  iis  much  from  the  possibility  of  recognition  retraction. 

Invocation  of  General  Recognizers.  A  second  kind  of  recognizer  invocation  mechanism  is 
provided  by  PSB;ise  for  general  recognizers.  In  contrast  to  the  invocation  of  continual 
recognizers  (including  their  quick  checks  for  applicability),  which  considered  a  fixed  set  of 


recogni/crs  and  a  small,  given  set  of  prcscniations  (lliosc  alTccted  by  (ho  latest  presentation 
editing  fiinelion).  invoeation  of general  reet)gni/ers  involves  searching  the  presentation  data 
base  and  a  larger  set  oCpotential  rccogni/ers. 

PSBase  supp()rts  two  kinds  oC  general  recogni/ers.  Ikuh  are  invoked  upon  a  particular 
presentation,  though  they  may  (and  typically  will)  examine  other  presctitalions  and  related 
domain  information  in  the  data  base.  The  llrst  kind  of  general  recognizer  interprets  user 
edits  to  presentations  that  were  created  by  presenters.  These  recognizers  arc  typically 
simple.  Uiking  advantage  of  the  existing  links  from  the  presentation  to  the  presented  domain 
object,  for  example,  one  such  recognizer  might  interpret  a  change  in  text  presenting  the 
reference  date  properly  of  a  file.  This  recognizer  simply  parses  the  text,  creates  a  new  date 
instance,  and  changes  the  value  of  the  file  property.  Note  that  it  does  not  need  to  deciu( 
between  recognition  as  a  date  and  as  something  else  --  it  already  knows  that  it  should  be  a 
date  presentation  from  the  presenter-recorded  infomitttion,  namely,  llic  presented  domain 
object  property  that  links  it  to  the  file's  rc/crence  property. 

Ihc  second  kind  of  general  recognizer  is  invoked  upon  presentations  for  which  there  is  no 
presented  domain  object  link,  i.e.,  presentations  whose  meaning  is  unknown.  This  kind  of 
recognizer  must  determine  the  kind  of  recognition  to  be  performed. 

Both  kinds  of  general  recognizers  arc  attached  to  classes  of  presentations  in  the 
presentation  data  base.  For  example,  the  paiscr  for  a  file's  reference  date  properly  would  be 
attached  to  the  text  presentation  class. 

The  invocation  mechanism  begins  by  scanning  the  edit  history,  determining  which 
presentations  have  changed  since  the  last  recognition.  Any  recognition  that  depended  on 
those  changed  presentations  is  retracted  if  possible.  This  h;is  the  elTcel  of  allowing  the  user 
to  make  changes  in  a  plan  (such  as  llic  Hired  plan  of  deletions):  the  effect  is  incremental 
recognition  of  the  changes,  but  no  specific  recognizers  for  incremental  changes  need  to  be 
provided. 


Second,  all  presentations  that  had  been  created  by  pre.scnters.  but  edited  by  the  user 


(since  llic  previous  general  recognilion).  are  colleeled.  Kor  each  of  these  presentations,  a 
general  recognizer  (of  the  first  kind  discussed  above)  is  invoked.  Selection  of  this  recognizer 
is  baseii  on  the  class  of  the  presentation  and  the  kind  of  property  (such  ;ls  reference  date). 

third,  recognilion  is  pertbrnieil  on  all  presentations  with  no  presented  domain  object 
properly  value,  i.e..  those  presentations  that  are  unrecognized.  (Note  that  sonic 
presentations  may  have  been  previously  recognized,  but  arc  now  unrecognized  because  of 
recognition  retraction.)  fhese  recognizers  are  also  invoked  based  on  the  class  of  the 
presentations  they  are  to  recognize. 

5.6  Basic  Style  Packages 

PSMasc  ofTcrs  a  supply  of  presenters,  recognizers,  and  combinations  that  the  user 
interface  builder  may  choose  to  use  as  components  in  a  user  interface.  In  a  sense,  one  such 
component  has  already  been  mentioned:  the  presentation  editor  functions,  taken  as  a 
whole. 

I’rescntcrs.  Three  presenters  arc  provided,  for  presenting  command  sets  as  menus,  for 
presenting  the  execution  monitor’s  current  state  by  highlighting  the  current  command,  and 
for  presenting  any  domain  object  by  a  noun  phrase.  Like  the  other  components  described 
here,  these  are  all  independent  of  any  particular  application  domain.  (This  is  not  strictly 
true,  as  the  first  two  deal  with  the  domain  of  commands;  however,  that  domain,  like  the 
domain  of  presentations,  is  universal  in  that  it  is  always  included  in  any  user  interface.) 

Command  Menus.  This  component  is  very  simple,  consisting  of  a  few  style  descriptions. 
Since  a  command  set  is  a  specialization  of  object-sequence,  where  the  elements  property  is  a 
list  of  command  descriptions,  a  sequence  presentation  style  can  be  used,  '['he  following  is 
the  description  for  a  vertical  command  menu  style.  (The  style  definition  for  horizontal 
menus  is  similar.) 


{ def- sequence-presen  tat  i  on- st^le  VERT  I  CAL -COMMAND -MENU 

COMMAND-SET  t 

nil  nil  ;  Not  active. 

nil  nil  nil  ;  No  prefix,  infixes,  or  suffix. 

just- name 

: ver t ica 1  - 1 ayout  :border-box  fonts : cptfontb ) 

Execution  State  Presenter.  PSHasc  provides  a  simple  presciuer  for  tlic  cxeeulion  monitor 
discussed  on  page  111.  The  presenter  is  invoked  whenever  the  execution  monitor  places  a 
command  or  command  application  instance  on  its  stack,  i.e.,  when  the  command  is 
executed.  The  presenter  examines  the  presentation  data  base  to  determine  whether  the 
command  or  command  application  is  being  presented.  If  it  finds  a  presentation,  it 
highlights  iL 

For  example,  when  the  user  invokes  the  erase  presentation  editing  command,  the 
execution  state  presenter  might  find  the  command  presented  iti  a  menu  of  editor 
commtinds.  Whether  the  user  invoked  the  command  by  referencing  that  item  in  the  menu 
or  by  typing  the  delete  key,  the  menu  item  is  highlighted  to  present  the  current  state. 

Thcic  arc  other  possibilities.  Consider  the  following  scenario;  A  comntond’s 
dcKumentation  is  currently  being  presented.  The  d(K:umentation  comprises  three 
paragraphs,  each  presenting  a  step  in  the  command.  As  that  command  executes,  the 
execution  state  presenter  will  highlight  tlie  three  paragraphs  in  sequence.  (1  he  presentation 
of  the  documentation  is  not  strictly  a  presentation  of  the  command.  The  presenter  will  still 
consider  the  documentation  presentation  as  a  suitable  reference,  using  a  special  version  of 
the  mechanism  for  resolving  references  to  essential  properties  discussed  in  section  5.1.) 

Phrasal  Presenter.  The  phrasal  presenter  produces  a  phrase  describing  a  domain  object, 
in  most  cases  a  noun  phrase  such  as  "the  file  OZ:<NSR>I,OGIN.CMD.4",  "a  plan  to  delete 
the  file  OZ:<NSR>DEMO.'IXT.r',  or  "the  reference  date  of  the  file 
OZ:<NSR>QUHUF.NOTES.l.  Friday.  March  23, 1984". 

The  presentations  have  composite  presentation  structure  that  follows  the  semantic  and 
grammatical  structure.  Ihc  user  can  tlicrcforc  reference  part  of  the  phrase  to  indicate  a 


doiiiiiin  objccl  other  lh;in  the  one  presented  by  the  entire  phrase.  Ibr  esaniple.  given  the 
reference-ilate  presentation  mentioned  above,  the  user  eoiild  referenee  just  the  sub-phrase 
"the  file  0/:<NSR>QUKUIl.NOrKS.r‘  and  therefore  indieate  die  file,  instead  of  its 
reference-date  property.  Similarly,  the  user  could  reference  just  the  date. 

I  he  interface  builde-  provides  a  set  of  dictionary  entries,  templates  used  by  the  phrasal 
presenter.  The  phrasal  presenter  and  its  dictionary  entries  are  simple  in  comparison  with 
those  developed  in  natural  language  systems  (e.g..  [McDonald  83]).  '['hey  should,  however, 
give  an  idea  how  natural  language  presenters  would  fit  into  a  more  powerful  presentation 
system  base,  and  the  scheme  used  here  is  quite  useful  as  it  is. 

in  essence,  the  dictionary  entry  hangs  off  a  class  node  in  the  data  base  network.  The  most 
specific  entry  for  a  given  instance  is  chosen,  'lliis  section  illustrates  the  phrasal  presenter  by 
showing  a  s;imple  entry  for  the  class  of  dale  instances.  Each  date  instance  has  four 
properties:  day  of  month,  month,  year,  and  day  of  week.  The  dictionary  entry  for  dale  refers 
to  dictionary  entries  for  the  values  of  these  properties. 

The  entry  is  written  as  the  : phrased- preienter-dictionary-entry  method  for  the  Lisp  flavor 
date,  the  flavor  implementing  the  date  class  in  the  data  base.  The  l  isp  details  below  can  be 
largely  ignored,  since  the  definition  is  simply  a  template.  The  template  has  slots  that  are 
filled  in  by  evaluating  Lisp  expressions;  these  slots  are  indicated  by  commas.  ITie  values 
filling  tlie  slots  may  be  other  fillcd-in  dictionary  entries.  The  result  is  a  grammatically 
structured  tree  of  text.  The  tree  is  annotated  with  the  domain  objects  being  presented. 

The  definition  therefore  drives  the  domain  collector  and  semantic  presenter,  but  luis  left 
the  text  positioning  details  up  to  a  standard  organizational  presenter.  (  The  organizational 
presenter  used  is  the  one  that  fills  a  rectangular  area  with  the  text,  as  a  paragraph  would  be 
filled.) 

The  following  is  the  dictionary  entry  as  the  builder  would  write  it.  to  produce  text  such  as 
'Thursday,  August  9. 1984." 


(defmethod  (DATE  :  PHRASAl.-PRESENI ER-D ICT lONARY-ENTRY )  () 

'(:SAY  .self 

( : FURTHER-INFO 

(; SAY-PROPERTY  (.self  :DAY-OF-WEEK) 

.(phrasal  presenter- diction ary -entry  day-of-week))) 

(:  SAY-PROPERTY  (.self  :MONTII) 

.( phrasal -presenter-diet ionary-entry  month)) 

(: SAY-PROPERTY  (.self  : DAY-OF-MONTH) 

.( phrasal -presenter-dictionary-entry  day-of -mon th ) ) 

M  M 

( :SAY-PROPERTY  (.self  :YEAR) 

.(phrasal -presenter-diet ionary-entry  year)))) 

The  tree  produced  has  the  following  items; 

*  An  identifying  symbol,  :say 

*  Ihc  presented  domain  object  -  the  date  insmnee,  since  self  will  be  bound  to  it 

*  A  sub-tree,  flagged  as  carrying  non-rcstrictivc  further  information,  that  aecesses 
the  dictionary  entry  for  the  day  of  week  property,  labeled  as  presenting  the  day 
of  week  property 

*  A  siiu-Licc  tiiai  accesses  tiic  Jictioiiaiy  entry  foi  iiic  month  property 

*  A  sub-tree  that  accesses  the  dictionary  entry  for  the  day  of  month,  similarly 
labeled  as  a  property  presentation 

*  Some  template  text,  a  comma 

*  A  sub-tree  that  accesses  the  dictionary  entry  for  the  year  property 

The  sub-trees  invoke  other  phrasal  dictionary  entries.  For  the  case  of  "Thursday.  August 
9,  1984.",  the  sub-tree  entries  would  produce,  respectively,  the  text  "ITiursday",  "August", 
"9",  and  "1984".  (  I  hese  are  single  words;  in  general,  the  sub-trees  might  themselves  specify 
more  complex  phrases.) 

The  general  phrasal  semantic  presenter  takes  this  specification  tree  and  produces  a 
composite  presentation  structure.  Figure  5-9  illustrates  the  resulting  presentation  structure 
and  its  relation  to  the  data  ba.se  network.  Some  very  simple  anaphora  prixcssing  is 
performed  if  possible  (not  possible  here).  Commas  arc  added  around  the  non-rcstrictivc 


further-info  stmcuircs.  1  lie  first  letter  is  eapitali/ed.  and  a  period  is  added  at  the  end.  The 
presenter  can  optionally  be  invoked  to  produce  a  briefer  presentation,  in  which  case  it 
ignores  the  sub  trees  marked  as  further  information. 

Uccogni/ers.  The  next  two  sub-sections  describe  particular  recogni/ers  and  recogni.  er 
frameworks  that  PSHase  provides,  for  rccogni/ing  presentation  editor  comi. lands  from 
sketches  and  for  recognizing  commands  from  the  movement  of  presentations. 

Curve  Recognizers.  Prc.sentation  editor  commands  may  be  invoked  in  two  general  ways, 
by  primitive  command  signals  (such  as  keystrokes  or  mouse  clicks)  and  by  recognition. 
Section  4.2  showed  c.xamples  of  Zmacs  editor  commands  invoked  by  recognition;  the  user 
can  type  command  names  or  select  commands  from  a  menu. 

PS  Base  offers  another  kind  of  extension  to  the  presentation  editor:  recognition  of 
presentation  editor  commands  by  "sketching  curves".  Figure  5-10  shows  the  screen's 
display  as  the  user  "sketches"  an  arrow  from  the  ellipse  to  the  rectangle.  The  user  sketches 
by  moving  the  mouse,  holding  a  mouse  button  down  until  the  curve  has  been  completed. 
The  curve  is  displayed  as  a  set  of  dots  while  the  user  is  drawing  it.  When  the  button  is 
released,  an  immediate  recognizer  interprets  the  creation  of  this  curve  as  a  presentation 
editor  command,  in  this  case  a  command  to  connect  the  ellipse  to  the  rectangle  by  an  arrow. 
Figure  5-11  shows  the  result. 

Note  that  these  sketched  curves  arc  not  just  recognized  as  presentations,  e.g.,  not  Just  an 
arrow.  They  are  recognized  as  presentation  editor  commands.  This  h;is  two  advantages. 
First,  the  user  can  understand  the  semantics  of  the  recognition,  since  the  results  are  just  as  if 
the  user  had  invoked  the  editor  command  directly  (assuming  that  the  interface  provides  the 
user  with  that  editor  command).  Second,  recognition  can  be  more  powerful  --  it  can  do 
more  than  just  create  a  presentation.  For  example,  one  could  write  a  curve  recognizer  that 
interpreted  a  sketched  line  through  a  presentation  as  a  command  to  delete  that  presentation. 

The  curve  recognizers  arc.  in  a  simple  .sense,  a  series  of  rules.  (1  his  is  not  a  complex 
rule-based  system  --  there  is  no  iteration  over  the  set  of  rules,  for  instance.  Also,  these  rules 


f'iyurt  5-10:  ikTorc  Curve  Recognition 


Figure  5-11:  After  Curve  Recognition 


do  not  Itavc  I’cclarativc  |iallcms.  but  instead  are  implemented  by  special  procedmes.)  I'bc 
rules  are  simple,  and  the  success  of  the  recognizers,  is  due  to  four,  inter-related  facts.  I  'irsl. 
there  are  few  possibilities  to  distinguish.  Ihese  will  be  listed  below.  Second,  the 
recognition  is  fa.st  etKrugh  to  be  usually  preferred  over  other  wa>s  of  invoking  the  same 
cmiimands.  I  liird.  the  user  can  see  the  result  and  change  it  if  the  recogni/ers  were 
mistaken.  F  ourth,  the  recogni/ers  are  al)le  to  use  the  presentation  data  base  to  great 
advantage.  A  discussion  of  the  curve  recognition  rules  will  clarify  the  bust  point. 

I'hcre  are  three  functions  that  examine  only  the  list  of  positions  defining  the  curve. 
(  These  functions  do  not  examine  the  presentation  data  base.)  1  hey  are  largely  responsible 
for  determining  the  kind  of  presentation  the  curve  appears  most  like;  line,  arrow,  circle, 
ellipse,  or  rectangle.  The  first  function  detennines  whether  the  curve  is  open  or  closed.  I'he 
second  determines,  for  open  curves,  w-hether  there  are  arrowheads  at  one  or  both  ends.  The 
third  produces  a  ranked  match  to  a  circle,  ellipse,  and  rectangle,  specifying  the  defining 
parameters  (e.g.,  center  and  radius  for  a  circle). 

These  functions  are  not  necessarily  always  invoked  --  they  are  invoked  by  die  rules, 
depending  on  the  presentation  data  base  structure.  As  these  determinations  are  made,  a 
description  of  the  curve  is  built  up  and  can  be  used  by  later  rules.  The  current  set  of  rules 
first  invokes  the  function  to  determine  whether  the  curve  is  open  or  closed.  If  open,  a  rule 
asks  whether  the  end  positions  lie  within  presentation.s;  if  so.  the  curve  is  an  object  of  class 
connecting  thing  (line  or  arrow).  If  open,  another  rule  determines  whether  there  are 
arrowheads,  and  extends  the  description  to  distinguish  between  line,  single-headed  arrow, 
or  two-heading  arrow.  Finally,  if  open  and  connecting,  a  rule  examines  whether  the  ends 
can  be  "pulled  out",  i.e.,  whether  there  is  a  surrounding  ellipse  or  box.  If  so,  the  line  or 
arrow  will  be  connected  to  that  outer  form. 

If  the  curve  is  closed,  a  rule  tisks  whether  the  curve  encloses  a  presentation.  If  so,  the 
recognized  command  will  be  ellipse  around  or  rectangle  around.  1  he  type  is  determined 
either  by  the  style  of  the  diagram  (e.g.,  only  ellipses  surround  text)  or  by  the  rule  that 
cltLssifies  closed  curves.  In  the  latter  case,  the  default  parameters  for  the  form  are  ignored; 
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the  command  will  compute  tl  ese  iVom  the  circumscribed  presentation. 


There  are  a  few  other  rules,  which  deal  with  particular  styles  of  diagrams.  These  rules 
produce  editor  commands  to  create  particular  patterns  of  presentations. 

Move  Recognizer  Mechanism.  PSHase  olTers  a  framework  for  implementing  continual 
recogni/ers  that  interpret  movement  of  presenLitions  tis  commands,  in  the  style  of,  for 
example,  the  Xerox  Star  and  Apple  l  isa  systems.  Seetion  4.3  illustrated  some  kinds  of  move 
recognition;  for  example,  moving  a  dcxiiment  presentation  to  a  printer  presentation  is 
recognized  :is  a  command  to  print  that  document 

A  move  recognition  driver  (or  just  driver  when  the  context  is  clear)  is  a  predefined 
continual  recognizer;  it  provides  the  first  phase  of  a  continual  recognizer,  checking  for 
applicability.  It  checks  for  a  move  command  and,  if  so,  determines  the  presentation  being 
moved  and  the  (po.ssibly  several)  presentations  to  which  it  has  been  moved.  It  then  matches 
these  possible  candidates  against  a  set  of  patterns  that  attacli  to  the  data  base  network. 

Each  pattern  has  ;ui  associated  second-phase  recognizer,  which  is  invoked  if  that  is  the 
pattern  that  matches.  (In  this  implementation  there  is  no  considcrtition  of  multiple  matches 
"  the  first  entry  who.se  pattern  matches  is  used.)  It  is  this  associated  recognizer  Uiat 
performs  tlie  actual  recognition  of  the  move  as  a  data  base  command.  This  division  of  the 
recognition  process  follows  the  division  described  in  section  2.6:  the  driver  is  the 
organizational  recognizer,  and  the  selected  recognizer  is  the  semantic  recognizer. 

A  sample  definition  of  one  of  these  pattcm-to-rccognizcr  associations  is  the  following,  the 
one  for  recognizing  movement  of  document  icons  to  printer  icons: 

(def-inove-recog nit  ion -rule  move-documen  t- to-pr i nte  r 
(roverlap  (file  (document- icon ) ) 

(printer  (printer-icon))) 

: recognize-pr inter-movement) 

The  second  and  third  lines  specify  the  pattern,  which  consists  of  three  parts.  The  first  part 
specifics  the  kind  of  overlap  between  the  presentation  being  moved  and  the  candidate 
destination  presentation.  This  am  be.  in  order  of  increasing  rcstrictivcness.  near,  overlap,  or 
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wilhiii.  This  relation  is  ciclcnnined  froni  the  presentations'  extent  boxes. 

The  next  two  elements  of  the  pattern  specify  the  class  of  presented  ilomain  object  and  the 
presentation  styles.  This  entry  specifies  that  the  presentation  being  moved  must  present  a 
file  in  the  dr)cumcnt-icon  style,  (luich  presentation  has  properties  connecting  it  to  both  the 
presented  domain  object  and  the  presentation  style  used  to  create  the  presentation.)  The 
entry  also  specifics  that  the  destination  presentation  must  present  a  printer  in  the  printer- 
icon  style. 

The  fourth  line  specifics  the  recognizer  that  will  create  a  command  application  for 
printing  the  file. 

Combinations.  The  next  three  sections  describe  modules  that  combine  presenters  and 
recognizers  into  larger  control  structures. 

Mouse-Tracking  Reference.  This  module  provides  a  mouse-based  reference  and 
documentation  facility.  A  simple  fast  recognizer  continually  watches  the  movement  of  the 
mouse  and  determines  whether  the  mouse  cursor  is  within  any  prc.sentation.  This  check  is 
made  using  the  presentations’  extent  boxes;  in  the  case  of  more  than  one  presentation 
containing  the  mouse,  die  one  with  the  smallest  extent  box  is  selected.  The  presentation 
data  btise  records  this  choice. 

At  the  stimc  time,  the  current  choice  is  presented  by  being  highlighted  on  the  screen. 
Thus,  as  the  user  moves  the  mouse,  the  highlighting  continually  shows  what  presentation 
contains  the  mouse  cursor. 

In  addition,  about  once  every  second  (i.e.,  at  a  rate  considerably  slower  than  the  operation 
of  the  tracking  recognizer  and  presenter  just  described),  a  documcntaiinn  ////cat  the  bottom 
of  the  screen  is  updated.  It  presents  the  current  choice  by  using  the  phrasal  presenter, 
described  earlier.  Ibis  can  help  to  disiimbiguatc  some  cases  where  the  highlighting  box 
alone  would  be  insufTicient.  It  can  also  be  helpful  in  providing  d(.x:umcntation  about  the 
presentation  style  -  c.g..  to  llnd  out  that  a  particular  number  in  a  directory  listing  is  the 


length  of' a  flic.  No  presentation  striictiire  is  created  for  tlie  drxiinienlation  line  -  the  result 
is  simply  a  text  string  --  though  the  anaphora  and  other  processing  is  performed,  further- 
information  sub-trees  arc  eliminated  if  the  resulting  string  is  Ux)  long. 

An  additional  reference  nrechanism  is  provided  that  allows  the  user  to  move  the  selection 
choice  up  and  down  the  hierarchy  of  presentations,  e.g..  moving  from  a  text  presentation  in 
a  directory  listing  up  to  the  row  presenting  a  file  or  to  the  entire  directory  presentation. 
Again,  this  choice  is  reflected  by  the  highlighting  and  phrasal  presenters  automatically: 
these  commands  affect  the  presentation  data  base's  record  of  the  current  choice,  which  is 
continually  and  automatically  presented  by  them. 

Open/Close  Mechanism.  Like  the  move  recognition  driver  discussed  above,  this 
mechanism  provides  a  general  framework  for  implementing  opening  and  closing  of  domain 
objects,  like  that  used  in  the  Xerox  Star  and  Apple  Lisa  styles  (see  section  4.3).  In  those 
systems,  opening  a  document  icon,  for  example,  causes  the  text  of  the  file  to  be  displayed. 

Opening  and  closing  domain  objects  can  be  thought  of  as  changing  presentation  styles. 
The  interface  builder  specifics  links  between  the  domain  object  class  and  the  opened  and 
closed  presentation  styles.  The  following  specification  is  typical: 

(def-open-ctose-presentation-style  fi 1  e-document 
file 

document-icon 
text-f i le -con  tents 
fonts : cptfont ) 

This  specifics  that  for  instances  of  cUiss  file  the  document  icon  style  will  be  used  for  the 
closed  presentation  and  the  text  file  contents  style  for  the  opened  presentation.  The  default 
font  for  the  opened  style  is  also  specified. 

The  open  command  is  given  a  presentation  as  rui  argument  and  a  position.  It  finds  the 
entry  for  the  presentation,  based  on  the  presented  domain  object,  and  invokes  the  presenter 
for  the  opened  presentation  style  specified  by  the  entry.  The  presenter  creates  the  opened 
presentation  at  the  given  position.  The  original  presentation  is  erased  but  remembered  its  a 
property  of  the  opened  presentation.  This  allows  the  original  presentation  to  be  redrawn 


when  the  opened  presentation  is  later  closed,  if  possible,  for  efllciency  atul  so  that  its 
original  position  is  restored. 

[  he  decisions  to  erase  and  record  the  original  presentation  are  a  matter  of  style  and  are 
easily  changed.  This  style  attempts,  by  having  only  one  preseiUation  of  a  domain  object  at  a 
time,  to  give  a  feeling  of  directness  -  that  the  visual  preseniaiion  is  the  domain  object,  and 
opening  is  a  "physical"  act.  However,  this  always-erase  rule  is  probably  too  simple:  there 
are  probably  certain  kinds  of  presentations,  e.g..  icons,  that  do  seem  "to  be"  their  presented 
domain  objects,  while  others,  e.g.,  phr;isal  presentations,  may  merely  "talk  about"  them. 

Rarlier  it  was  mentioned  that  opening  and  closing  can  be  considered  to  be  a  matter  of 
changing  presentation  styles.  However,  there  is  another  consideration  that  must  generally 
be  made:  signalling  the  application  data  base  that  more  detail  is  needed  from  the  outside 
world  or  that  it  is  time  to  save  such  detail,  dhis  issue  is  raised  when  the  application  data 
base  is  a  model  of  some  outside  world.  An  opened  presentation  typically  involves 
presenting  much  more  domain  infonnaiion  than  a  closed  presentation.  (For  example,  a 
dcKiimcnt  icon  may  only  be  labeled  with  the  file  name,  while  an  opened  presenUition 
contains  the  file's  text) 

riiereforc,  the  open  command  also  sends  a  message  to  die  presented  domain  object  to  be 
sure  that  its  contents  are  fully  described  and  updated.  For  a  file,  Uiis  may  involve  getting 
the  file's  text.  F,ach  chiss  of  domain  object  can  provide  its  own  method  for  handling  this 
message,  or  inherit  a  more  general  one.  The  default  method  is  to  do  nothing. 

Closing  an  object  requires  two  actions  in  addition  to  the  presentation  style  change.  First, 
recognition  of  editing  changes  to  the  open  presenuuion  must  be  performed.  Thus,  in 
general,  the  user  may  have  changed  some  of  the  parts  of  the  opened  presentation,  and  Uiese 
changes  arc  reflected  in  changes  to  the  presented  domain  object's  contents  in  some  way. 
Second,  the  domain  object  is  .sent  a  message  to  s;ivc  its  contents.  For  a  file,  this  involves 
Siiving  the  file's  text.  Again,  the  inherited  default  is  to  do  nothing. 


Top-Level  Control  Structures.  PSIiiise  provides  two  alternative  control  structures  that 


processes  command  signals  (keystrokes  and  mouse  clicks),  invoke  immediate  and  other 
recogni/ei’s.  and  cause  graphics  redisplay  to  be  performed.  They  differ  primarily  in  the 
method  of  command  invocation  and  command  argument  selection.  In  the  first  top-level 
style,  the  user  first  specifies  a  command,  then  selects  its  arguments;  in  the  second  style,  the 
user  selects  the  arguments  fust,  then  specifics  the  command. 

The  first  style  has  the  benefit  of  the  command's  description  while  selecting  the  arguments 
for  the  command.  The  parameter  descriptions  have  control  of  the  selection,  prompting  the 
user  with  the  parameter  name  and  documcnuition,  and  checking  that  the  argument  selected 
is  of  the  proper  type.  For  e.\ample,  if  the  parameter  specifics  that  a  file  must  be  selected,  it 
will  immediately  reject  any  selection  that  is  not  a  file,  letting  the  user  make  the  selection 
again.  Though  the  style  as  provided  does  not  do  this,  it  would  be  a  relatively  simple  matter 
to  tailor  the  mouse-tracking  mechanism  so  that  only  presentations  of  the  correct  type  would 
be  sensitive  to  selection,  i.e.,  only  those  being  highlighted  as  the  mouse  moved  across  tlicm. 

The  second  style  collects  selected  arguments,  presenting  them  by  keeping  them 
highlighted  until  the  command  is  chosen,  and  then  when  a  command  presentation  is 
selected,  creates  a  command  application  for  it,  letting  the  command  application  check  tliat 
the  arguments  are  of  the  proper  type. 

Each  style  allows  two  kinds  of  mouse  clicks  to  be  made:  a  left-button  click  selects  a 
presentation  or  its  presented  domain  object,  and  a  right-button  click  selects  a  position.  In 
the  second  style,  positions  arc  highlighted  with  a  small  circle-cross  mark. 

Both  styles  select  commands  (as  opposed  to  their  arguments)  similarly.  If  tlie  user  types  a 
key,  that  key  is  tiiinslated  into  a  command,  using  a  standard  dispatch  tabic.  On  the  other 
hand,  when  the  user  selects  a  prcsenuition.  the  top  level  checks  whether  its  presented 
domain  object  can  be  resolved  to  a  command  -  i.e.,  a  simple  command  recognition  is 
performed.  Ihis  is.  for  example,  what  happens  when  the  user  selects  an  item  in  a  command 
menu. 

Similarly,  when  the  user  selects  a  presentation  of  a  command  application,  that  command 


applicalion  is  executed,  (n  this  ease,  however,  (lie  command  application  already  supplies 
the  arguments. 

After  each  selection,  whether  argument  or  command,  immediate  recognizers  are  invoked, 
and  graphics  redisplay  is  performed  if  there  is  no  typeahead  to  pnxess.  In  addition,  the 
second  top-level  style  executes  any  command  applications  that  have  been  accumulated,  by 
recognizers  such  as  move  recognizers.  On  the  other  hand,  the  first  style  allows  command 
applications  to  be  accumulated  without;  in  general,  immediate  execution.  This  is  the  case 
when  those  command  applications  are  presented,  as  just  mentioned  above.  Section 
4.1  illustrated  such  "plan  presentations"  in  Emacs  Dired. 

5.7  Summary 

This  chapter  opened  with  some  general  comments  about  the  benefits  of  a  presentation 
system  base,  and  in  particular.  PSBasc.  Summarizing  these  brielly;  The  stnicturc  of  PSBase 
is  based  on  the  structure  of  the  general  presentation  system  model.  This  is  the  source  of 
much  generality  and  modularity,  in  both  PSBase  and  the  interfaces  built  on  top  of  it.  In 
particular,  domain-independent  and  style-independent  parts  can  be  identified  and  provided 
in  the  base.  Purthennore,  most  of  the  modules  in  PSBasc  rely  heavily  on  the  uniformity  of 
the  data  base  network,  which  is  used  to  implement  both  the  presentation  data  base  and  the 
application  data  base. 


Chapter  Six 

Constructing  Presentation  Systems 


This  chapter  ilkisiratcs  the  utility  of  the  presentation  system  base.  f’SHase.  by  discussing 
three  user  interfaces  constructed  oti  top  of  the  base.  The  interfaces  differ  in  style,  but  share 
the  same  purpose,  to  provide  an  interface  to  the  'rops-20  operating  system  top  level  ['rops20 
80],  as  docs  the  Hxcc,  Tops-20's  normal  top  level.  'I'hc  sections  below  will  describe  how 
these  interfaces  arc  constructed,  emphrisi/.ing  how  much  of  the  PS  Base  mechanism  is  shared 
between  them  and  how  relatively  little  needs  to  be  written  by  the  interface  builder. 
( riiroughout  this  chapter,  the  term  user  refers  to  the  user  of  the  constructed  interface.  The 
term  interface  builder  or  jusl  builder  refers  to  the  person  who  constructs  the  interface  using 
the  PS  Base  tools  and  mechanisms.) 

6.t  The  User’s  View  of  the  Three  Interfaces 

The  sections  below  will  briefly  illustrate  the  three  interfaces  by  discussing  scenarios  in 
which  tlic  user  views  directories,  files,  mail,  and  user  information:  edits  some  of  these; 
prints  and  deletes  files;  and  sends  messages.  Each  scenario  has  the  same  fictitious  user, 
Norman  S.  Rafferty,  whose  login  name  is  NSR.  The  host  computer  is  MIT-OZ.  The 
discussion  will  be  accompanied  by  diagrams  showing  the  screen  at  various  points  during  the 
scenarios.  In  order  to  s;ive  space,  not  all  steps  in  the  scenarios  will  be  shown. 

The  first  interface  incorporates  a  style  simitar  to  the  Xerox  Star  discussed  in  chapter  four, 
emphasizing  the  manipulation  of  icons.  I'hc  second  interface  incorporates  a  style 
emphasizing  the  use  of  text  displays  with  asswiated  command  menus.  I  hc  third  style 
incorporates  a  style  emphasizing  the  use  of  graphical  annotations,  an  extension  of  the  Hmacs 
Dired  style  discussed  in  section  4.1. 


I'hc  annotation  interface  is  somewhat  less  complete  than  the  other  two  in  that  it  offers  an 


interface  to  the  file  system  only.  This  is  not  an  inherent  limitation,  but  instead  reflects  the 
fact  that  the  current  implementation  of  PSBase  offers  less  support  for  building  the 
annotation  interface  than  for  building  the  others. 

It  is  not  the  intention  of  this  report  to  argue  that  these  particular  interface  styles  arc  ideal 
or  even  gcwxl  as  implemented  here.  The  styles  represent  three  different,  important  classes  of 
styles.  The  important  point  is  how  these  interfaces  can  be  designed,  constructed,  and 
changed  more  easily  given  a  presentation  system  biisc  on  which  to  construct  them. 

Icon-.Stylc  Interface.  The  initial  screen  display  of  the  icon-style  interface  scenario  is 
shown  in  figure  6-1.  At  the  top  left  is  a  cU)ck.  updated  every  minute.  Below  it  are  icons  for 
an  in-box  (received  mail),  out-box  (for  sending  mail),  two  printers  (the  Dover  laser  printer 
and  a  line  printer),  ruid  a  campfire  (used  for  deleting  files).  Across  the  top  arc  icons 
showing  the  users  currently  logged  in.  (One  of  the  user  figures  is  not  in  his  chair.  This 
indicates  that  the  user  has  not  typed  anything  within  the  last  twenty  minutes  and  is  perhaps 
awav  from  the  terminal.)  The  user  display  is  undated  every  few  minutes.  Below  the  users 
are  three  folder  icons,  prescntitig  NSR’s  three  directories,  NSR,  NSR.R,  and  NSR.R.T. 
(These  happen  to  be  hierarchically  nested  directories,  the  directories  owned  by  this  user, 
though  any  set  of  directories  can  be  displayed.) 

The  UoCr  opens  the  NSR.R.T  folder;  First,  the  folder  icon  is  selected,  by  pointing  to  it 
with  the  mouse  and  pressing  a  mouse  button.  While  selected,  the  icon  is  displayed  in 
reverse  video.  The  mouse  is  used  to  select  a  position  for  the  opened  presentation.  ITie  user 
types  a  special  open  command  key.  1  he  folder  icon  disappears  and  a  new  display  showing 
the  contents  of  the  directory  appears  at  the  j^lcctcd  position,  tis  shown  in  figure  6-2.  This 
display  shows  (he  files  in  the  directory,  as  a  set  of  document  icons,  the  full  directory  name, 
and  disk  space  information.  I  hc  "6/20221"  indicates  that  this  directory  uses  6  disk  bkx;ks, 
and  20221  disk  blocks  remain  free. 

While  this  opened  directory  is  displayed,  it  will  be  periodically  updated.  If  the  number  of 
free  disk  bltK'ks  changes,  the  "20221"  will  be  replaced  by  tlic  new  amount  Also,  the 
d(Kumcnt  icons  will  change  if  the  set  of  files  in  the  directory  changes. 


Figure  6-1:  Icon-Style  Interface 
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I'iyure  6-2:  Icon-Slylc  Inlerfuce 


Next,  the  user  opens  the  file  MSGJXT.  I'hc  process  is  the  same  as  before:  the 
document  icon  is  selected,  a  position  is  selected,  and  the  open  command  key  is  typed. 
F  igure  6-3  shows  the  screen  at  this  point.  'I'he  MSCJ'Xl'kon  no  longer  appears  in  the 
directory  display,  since  it  has  been  brought  out  to  tlie  desktop  area  and  opened.  When 
closed,  it  will  retake  iLs  place  in  the  directory  display  as  a  dcK'ument  icon. 

Figure  6-3  also  shows  a  change  in  the  logged-in  user  display:  die  set  of  users  has 
changed. 

The  user  edits  the  text  of  the  MSG.TXT  file.  A  position  within  the  text  is  selected,  and 
the  set  edit  point  command  key  is  typed.  A  text-editing  cursor  appears  at  that  place  in  the 
text.  f-Tliting  takes  place  by  using  simple  Emacs-like  command  keys.  For  instance,  typing 
letters  inserts  them,  and  typing  certain  comrol-cliaractci's  moves  the  cursor  or  deletes 
characters. 

The  user  also  edits  the  To  field  (i.c.,  destination  specification)  at  the  top  of  the  opened  file 
display.  T  his  indicates  the  user  who  will  receive  Uiis  file  if  it  is  mailed  (put  in  the  out-box). 
This  editing  is  performed  in  the  same  manner  as  the  text  editing  just  discussed.  The  result, 
shown  in  figure  6-4,  is  diat  the  user  FCD  at  MIT-OZ  will  receive  a  copy  of  diis  file  when 
mailed. 

The  user  now  closes  MSG.TXT,  by  selecting  it  and  typing  the  c/o^c  command  key.  The 
opened  file  display  disappears.  ;uid  the  tlocumcnt  icon  reappeare  in  the  opened  directory. 

Next,  the  file  TEST.TXT  is  printed.  The  document  icon  is  selected,  a  position  at  the 
Dover  icon  is  selected,  and  the  move  command  key  is  typed.  The  print  icon  is  highlighted  to 
show  that  the  print  command  has  been  understood  and  is  underway.  (The  background 
prcKcss  sends  a  request  is  made  to  the  host  computer  to  print  the  file.)  I'he  highlighting  is 
then  turned  off.  and  the  document  icon  is  positioned  adjacent  to  the  printer  icon.  See  figure 
6-5. 

After  printing,  the  user  deletes  the  file  by  moving  the  T'/aVT’.TA'/’ document  icon  to  the 
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campfire.  The  campdre  is  tiighlighled  as  ihe  file  is  deleled.  ITe  highlighling  is  llien  lurncd 
off  and  ihe  dociimeiU  icon  disappears. 

riie  user  mov  es  ilie  ATSYf.  7T  /'d(x:iimem  icon  out  of  the  directory  to  the  desktop,  i.e.,  the 
open  part  of  the  screen.  Ihe  user  now  closes  the  directory;  the  original  folder  icon  is 
displayed,  instead  of  the  opened  directory  display.  Sec  figure  6-6. 

Mail  is  viewed  by  opening  the  in-box  icon.  This  opened  presentation  shows  the  messages 
in  the  mail  file  as  summary  lines,  shown  in  figure  6-7.  A  summary  line  can  be  opened, 
showing  the  text  of  the  tnessage.  I  his  process  is  similar  to  that  for  viewing  directories  and 
files. 

The  user  can  send  the  contents  of  a  file  in  two  ways.  First,  he  can  move  the  document 
icon  to  one  of  the  user  icons  at  the  top  of  the  screen.  This  causes  the  text  of  the  mes.sagc  to 
appear  as  a  message  on  that  user's  tcnninal.  Second,  the  document  icon  can  be  moved  to 
the  out-box.  The  user  takes  the  latter  action,  moving  the  MSG.TXT document  icon  to  the 
out-box,  causing  the  contents  of  the  file  to  be  mailed  to  the  user  I'CD. 

Finally,  the  user  opens  the  NSR  icon  representing  himself,  displaying  information  about 
his  terminal  location  and  personnel  information,  such  as  office,  supervisor,  etc.  This  is 
shown  in  figure  6-8.  He  updates  the  office  information,  using  the  same  text-editing  process 
described  above,  and  then  closes  the  display. 


rijjurc  6-6:  Icon-Style  Interface 


Figure  6-8:  Icon-Style  Interface 


UName:  NSR  Fork;  FINGER 

Idle:  Location:  MIT-LISPM-2  (Chaos) 

Norman  S.  Rafferty  (Norm) 

Office:  NE43-809  ,  x3-5871  .  working  for  HENSON. 


Menu-Style  Interface.  F  igiiic  6-9  sliows  the  initial  screen  display  at  the  start  of  the 
scenario  for  the  nieiui-stylc  interface.  Across  the  top  is  a  display  of  current  information 
about  the  status  of  the  host  computer;  the  time,  the  time-sharing  load,  and  the  number  of 
jobs.  (  The  time-sharing  load  on  l'ops-20  is  represented  by  three  bad  uverases.  the  first 
specifying  the  load  at  the  current  time,  the  second,  the  average  load  over  the  past  5  minutes, 
and  the  third,  the  average  load  over  the  past  15  minutes.)  This  display  is  updated  every  few 
minutes. 

Two  command  menus  are  displayed  below  the  host  information.  The  top  menu  contains 
commands  for  chcx)sing  what  to  present  and  for  updating  the  host's  itiformation  from  user 
editing  of  the  presentations.  (The  latter  is  the  perform  changes  command.)  The  bottom 
menu  contains  presentation  editor  commands.  These  commands  are  invoked  by  command 
keys  in  the  icon-style  interface. 

The  scenario  starts  with  the  user  invoking  the  present  directory  command  (the  result  of 
which  is  shown  in  figure  6-10):  The  user  first  points  to  the  menu  item  and  selects  it  by 
pressing  a  mouse  button.  A  small  window  appears  at  the  bottom  of  the  screen,  requesting 
that  the  user  type  the  directory's  pathname.  The  user  types  the  pathname  "<NSR,R,T>" 
(and  c;in  edit  it  using  the  text-editing  commands).  When  the  user  types  the  End  key,  the 
small  window  rlisappears,  and  the  user  is  prompted  for  the  next  argument,  the  position  for 
the  directory  presentation.  Tlie  interface  displays  Utese  prompts  (for  domain  object, 
presentation,  and  position  selection)  briefly,  in  a  line  at  the  bottom  of  the  screen  (not  shown 
in  these  pictures),  by  specifying  the  kind  of  command  argument  expected.  Here,  the 
prompt  is  "Position".  The  user  selects  a  position  with  the  mouse,  and  the  directory  is 
displayed  as  shown  in  figure  6-10.  While  the  command  is  being  executed,  i.c.,  until  the 
directory  display  appears,  the  present  directory  item  in  the  menu  is  highlighted  by  reverse 
video. 

The  directory  display  is  accompanied  by  a  menu  of  commands  that  view,  delete,  and  print 
files.  The  user  invokes  the  present  fde  command  from  that  menu,  and  then  selects  (as  an 
argument  to  the  command),  the  MSG.'f'XT  file.  This  selection  can  be  dime  by  pointing  to 
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Figure  6-10:  Menu-Style  Interface 
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just  the  text  presenting  the  name  of  tlie  Hie.  "MSG.  TX  I ",  the  entire  Hie  row.  or  even  the 
presentations  of  the  file's  properties  (siieh  as  the  "1"  presenting  the  file  length).  I  he  user 
also  selects  a  |K)sitit)n  for  the  file  display. 

Ihe  user  at  this  point  can  edit  the  file  and  its  io  field,  just  as  in  the  icon-style  scenario. 
See  figure  6-11. 

I  he  user  prints  the  llle  l.OGIN.CM D  by  selecting  Dover  Print  Pile  and  the  lllc  entry  in 
the  directory.  (Note  that  if  the  user  wished  to  print  MSG.TXT this  point,  he  could  cither 
select  its  entry  in  the  directory  or  select  the  file  display.)  As  before,  while  the  command 
executes,  its  item  in  the  menu  is  highlighted. 

I  hc  user  next  deletes  LOGIN.CMD.  Now,  in  addition  to  the  highlighting  of  the  delete 
command  menu  item,  the  LOGIN.CMD  line  is  removed  from  the  display,  as  shown  in 
tlgiire  6-12. 

The  user  now  erases  the  directory  listing.  (This  is  not  a  delete  command  --  it  just  removes 
the  directory  display  from  view.) 

A  display  of  the  current  user  jobs  is  next  displayed,  illustrated  in  figure  6-13.  From  left  to 
right,  the  fields  in  this  display  are:  login  name,  user  name,  current  job,  and  terminal 
information.  The  terminal  infonnation  starts,  in  some  cases,  with  the  time  the  terminal  has 
been  idle  (1:17  for  one  user,  1  minute  for  another  here)  and  follows  with  the  terminal 
I'xiation.  I  he  user  can  get  the  identification  of  these  fields  by  pointing  to  tlicm  with  the 
mouse:  the  documentation  line  at  the  bottom  of  the  screen  (not  shown  here)  shows  a  phrase 
identifying  the  field.  For  example,  pointing  to  the  text  "MIT-LISPM-2  (Chaos)",  the  user 
secs  "the  location  of  the  terminal  of  the  user  NSR,  Norman  S.  Rafferty",  fhe  user  edits  this 
field  to  add  more  information,  changing  it  to  "LM2:  7th  lloor".  He  makes  this  change  take 
effect  by  invoking  the  perform  c/ia/7ge.T  command  from  the  menu  at  the  top  left.  Sec  figure 
6-14. 


fhe  user  next  erases  the  user  display  and  invokes  present  mail,  resulting  in  the  display 


Figure  6-11:  Menu-Siylc  Interface 


Norn 


Figure  6-12:  Menu-Style  Interface 


Fitjurc  6-13:  Mcnu-Slyle  Interface 


Figure  6-14:  Menu-Style  Interface 


shown  in  (igurc  6-15.  llic  mail  .summary  display  is  acfompamcd  by  a  ivcnu  ol  a)mmaml.s 
for  \  icvving  messages  or  seiuling  llic  coiuonts  of  files  as  messages.  1  he  user  ean  nutil  or 
(/s(7id  (i.e.,  send  to  a  terminal,  so  the  recipient  secs  the  message  quickly)  by  selecting  the 
command,  the  MSG.  1X7'  file,  and  then  a  user,  fhere  are  a  number  of  ways  of  selecting  the 
recipient  user,  because  there  can  be  a  number  of  user  presentations  displayed:  in  the  7'u  of 
a  file  display,  in  a  display  of  user  jobs,  and  in  message  summary  lines. 


Figure  6-15:  Menu-Style  Interface 
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Annotation-Style  Interface.  1  he  initial  screen  display  for  the  annotation  style  interface  is 
very  .similar  to  that  for  the  mcmi-stylc  interface.  A  new  command,  recognize,  appears  in  the 
top  menu,  and  the  nre.scntation  editor  menu  has  been  e.\panded  to  include  commands  for 
tlravving  lines  and  arrows.  In  titldition,  the  interface  ofTcrs  the  user  the  curve-recognition 
facility  for  creating  lines  and  arrows.  This  expanded  menu  reflects  the  larger  role  the 
presenuition  editor  plays  in  this  style  of  interface:  die  user  creates  graphical  annotations  to 
presenuuions  displayed  by  the  system.  See  the  upper  left  portion  of  figure  6-16. 

The  user  starts  by  presenting  the  directory  <NSR.R.T>.  As  with  the  menu-style  interface, 
the  user  selects  (he  menu  item  and  is  prompted  for  pathname  and  position.  The  directory 
display  in  this  interface,  however,  docs  not  include  an  associated  menu  of  commands. 

The  user  first  decides  to  correct  some  information  in  the  directory,  namely,  that  the 
author  of  the  file  EM ACS.INIT.374,  currently  NSR,  really  should  be  EAK.  To  do  this,  the 
user  invokes  the  set  point  command  to  place  the  text-editing  cursor  in  an  area  above  the 
display  and  then  types  the  text  "CHANG P2".  The  text  "EAK"  is  created  nc.irbv  in  a  similar 
manner,  fhe  user  then  connects  "CHANGE"  to  the  author  prcsendition  by  a  line,  and 
connects  "CHANGE"  to  "EAK"  by  an  arrow.  The  result  is  shown  in  6-16. 

To  check  that  the  system  will  correctly  understand  this  annotation  command,  the  user 
inyokes  the  recugn/zc  command.  Up  to  this  point,  the  text,  line,  and  arrow  created  by  the 
user  had  not  been  recognized  by  the  interface.  Tlie  recognize  command  specifically  invokes 
the  annotation  recognizer.  The  menu  item  is  highlighted  while  the  recognition  is  being 
perfonned.  The  user  then  checks  the  result  of  the  recognition  by  pointing  to  the  text 
"CHANGE".  1  he  documentation  line  now  displays  "a  plan  to  change  the  author  of  the  file 
0/.:<NSR.R.T>ElVIACS.lNlT.374,  NSR,  to  EAK."  This  change  has  not  yet  been  made 
-  the  user  has  only  had  the  system  confirm  the  meaning  of  the  planned  command. 

I  he  user  next  makes  several  more  annotations,  as  shown  in  figure  6-17.  These  tell  the 
system  to  set  die  reference  date  of  the  file  EM  ACS. IN  17.374  to  be  the  same  as  its  creation 
dale,  delete  the  file  L0GIN.CMD.34,  and  print  the  file  TEST.TXT.L 


Figure  6-16:  Annotation-Style  Interface 
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Figure  6-17:  Annolaiion-Siylc  liuerfacc 
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I  hc  user  now  lolls  the  system  to  perform  these  commands,  by  inu)king  the  perfarm 
t7;w/gc.v  command,  fhe  command's  menu  item  is  highlighted.  The  first  thing  the  interface 
must  do  is  recogni/c  the  new  annotations,  so  the  recognize  command  is  automatically 
iinoked  by  the  interface.  1  he  user  sees  that  this  is  taking  place:  the  recognize  menu  item  is 
now  highlighleil.  After  recognition,  the  commands  arc  executed  one  by  one.  As  with  the 
highlighting  of  the  recognize  command,  the  user  secs  the  progress  of  the  perform  changes 
command:  the  annotation  commands  are  highlighted  while  they  are  being  executed. 

When  the  annotation  commands  have  all  been  performed,  the  display  is  updated  in  two 
ways.  First,  the  line  in  the  directory  presenting  the  file  IX)GIN.CMD.34  is  removed,  since 
the  file  h<us  been  deleted.  Second,  the  annotation  verbs  arc  changed  to  past  tense.  The 
resulting  display  is  shown  in  figure  6-18. 

6.2  Common  Implementation  Details 

Tlic  basic  order  of  development  of  the  user  interface  was  as  follows; 

*  Create  application  data  base  network  and  a  background  process  to  connect  it 
with  the  operating  system. 

*  Define  some  initial  presentation  styles  so  that  further  development  can  be  tested 
with  them  (c.g.,  icons). 

*  Fnabic  selected  PSRasc  basic  style  packages,  especially  top-level  control 
structure,  edit  functions,  and  the  mouse-tracking  reference  mechanism. 

*  Define  and  describe  commands  and  command  sets,  select  menu  presentation 
styles. 

*  Specify  move  recognition  and  open/close  rules. 

*  Write  recogni/ers  as  needed  (move  recognizers,  direct-edit  recognizers). 

*  Define  and  change  prcsenUition  styles  as  desired. 


Common  Implementation.  Certain  parts  of  the  user  interface  impicmcnuilion  are  shared 
between  all  Uiree  of  the  styles.  I  hese  parts,  once  constructed,  are  invariant  under  further 


development  and  experimentation  with  interface  styles. 


The  mo.si  important  of  these  parts  is  the  application  data  base,  whose  development  will  be 
discussed  separately  in  the  following  sub-section.  The  application  data  btisc  models  the 
operating  system,  and  at  first  it  seems  reilundant.  Yet  it  is  well  worth  the  modest  effort  to 
construct  it;  flic  uniformity  of  the  data  base  network  is  vital  to  the  utility  of  the  PSBtisc 
mechanisms.  In  future  systems,  applications  may  be  built  from  the  first  with  this  kind  of 
data  btisc,  completely  relieving  the  interface  builder  from  this  work.  (The  benefits  of  a 
uniform  d;ita  base  mechanism  in  modeling  the  application  arc  not  limited  to  the 
mechanisms  of  the  user  interface.)  A  sub-section  below  discusses  the  continual  updating  of 
the  application  data  b;tsc  in  more  detail. 

A  number  of  simple  parsers  are  provided  as  part  of  tlie  general  recognizer  mechanism 
that  recognizes  user  edits  of  property  presenLitions.  These  arc  called  d/recl  edits  and  are 
also  discussed  in  detail  in  a  sub-section  below. 

Finally,  all  the  styles  share  a  number  of  PSBtise  components.  Since  these  components  are 
simply  selected  and  enabled,  requiring  almost  no  work  on  the  part  of  the  interface  builder, 
the  componenLs  that  appear  in  the  three  style  implementations  will  be  listed  here: 

*  The  two  top-level  control  structures  (argument-first  for  the  icon-style 
implcmcnuition;  command-first  for  the  menu-style  and  annotation-style 
implementiUions) 

*  The  command  execution  presenter  (for  highlighting  commands  as  they  execute) 

*  The  moLise-tracking/rcfcrcnce  mechanism 

*  Vertical  command  menu  presentation  styles  (for  the  menu-style  and  annotation- 
style  implementations) 

*  Presentation  editor  functions:  all  styles  include  more,  set  text  cursor  position, 
and  text-editing  commands;  menu  style  adds  erase,  annotation  style  adds  line 
and  arrow 


*  Curve  recognizers  for  the  annotation  style. 


The  Application  Data  Base.  Like  PSUase,  this  interface  is  implciiicnicil  on  tlic  Ml  1  Lisp 
machine.  The  l.isp  machine  acLs  as  the  users  terminal:  the  Lisp  machine  communicates 
with  the  host  computer  via  network  conneetions.  The  user  of  the  iiucrracc,  however,  does 
not  need  to  be  aware  of  these  connections. 

1  he  large  scale  structure  of  this  system  is  shown  in  figure  6-19.  The  application  data  b;isc 
models  the  current  state  of  relevant  parts  of  the  host  computer,  using  the  uniform  data  base 
mechanism  provided  by  PSUase.  A  background  prcKCSS  maintains  the  application  data  base 
by  periodically  polling  the  host  computer,  getting  information  about  the  users  currently 
logged  in,  the  time-sharing  load,  the  contents  of  relevant  directories,  and  the  contents  of  the 
user's  mail  file  ("in  box"). 

Some  host  information  is  retrieved  or  stivcd  upon  demand,  rather  than  by  regular  polling. 
For  instance,  when  the  user  opens  a  document  icon,  the  presented  file  instance  in  the 
application  tiata  base  receives  a  make-contents  message:  the  file  instance  must  expand  its 
description  to  include  the  text  contents  of  the  file.  At  this  point,  therefore,  the  file  is  read 
into  the  IJsp  machine  from  the  host  computer.  Similarly,  when  the  file  instance  receives  a 
save-contents  message,  the  text  of  the  file  is  written  back  to  the  host  computer. 

Recognizers  for  Direct  Editing.  Three  insUtneesof  direct  editing  of  a  presentation  occur 
in  the  icon-style  interface  scenario:  editing  of  the  file  text,  the  file  destination  field,  and 
fields  in  the  user  information  display.  All  such  direct  editing  is  handled  in  the  sttme 
manner.  7he  PSflase  recognizer  control  structure  finds  those  presentations  created  by 
presenters  and  edited  by  the  user.  For  each  of  these,  it  invokes  a  specific  rccogniz.er  to 
handle  that  kind  of  prescnUition;  currently,  only  text  presentations  have  such  a  recognizer. 
1  his  recognizer,  still  part  of  the  general  mechanism,  checks  for  a  parser  specifically  for  the 
kind  of  presented  domain  object  and  invokes  it 

The  interface  builder  must  therefore  provide  such  parsers  for  those  kinds  of  application 
data  base  instances  that  arc  speeii'c  to  this  interface.  The  following  are  two  stimplc  parsers. 
Note  that  both  are  specified  not  by  the  class  of  domain  object,  but  by  the  property  name. 
Text  presentations  that  arc  directly  edited  arc  presenuttions  of  properties  (since  they  arc 


parts  of  a  larger  style).  This  approach  is  clearly  limited;  for  instance,  even  if  based  on  the 
property  name,  the  specification  really  should  include  the  kind  of  owning  object  or  the  kind 
of  properly  value,  since  properly  name  alone  may  be  ambiguous. 

(defmethod  ( TEXT-PRESI NTAf ION 

: PARSE -WORK -PHONE -PRESENTED-DOMA IN-OBJECT )  ( ) 

string) 

(defmethod  (TEXT-PRESENTATION 

;PARSE-REEERENCE-DATE-PRESENTED-DOMAIN-OBJECT)  ( ) 
(make- i nstance  'date 

' : un i versal -time  ( t  ime ; parse-uni  versa! -t ime  string 

0  nil  nil))) 

The  first  parser  simply  returns  the  string  of  the  text  presentation  ;is  the  siring  to  use  for 
the  value  of  the  presented  domain  object's  property.  In  fact,  most  of  the  parsers  for  these 
interfiices  have  such  trivial  parsers,  since  most  of  these  properties  have  string  values.  Here, 
for  example,  the  user  insuince  in  the  application  data  base  has  a  work  phone  property,  its 
value  is  not  a  data  base  instance,  but  is  simply  a  string. 

The  second  parser  is  only  slightly  more  complicated.  The  reference  dale  properly  of  a  file 
instance  has  a  value  that  is  a  dale  instance.  The  date  instance  in  turn  has  a  universal  time 
property,  encoding  a  lime  or  date  as  a  number.  I'he  Lisp  machine  provides  a  package  of 
functions  for  manipulating  such  lime  representations,  including  the  parsing  function  used 
here  that  returns  a  universal  time  given  a  string.  Thus,  there  are  two  phases,  the  actual 
parsing  of  the  string  and  the  creation  of  the  data  base  instance.  (These  phases  arc  simple 
cases  of  what  section  2,6  described  as  the  semantic  recognizer  and  domain  changer  parts  of 
the  recognizer.) 

The  number  of  parsers  to  be  specified  varies  with  the  number  of  properties  in  the 
application  data  base  that  will  be  edited.  U  docs  not  depend  on  the  number  of  presenUUion 
styles  presenting  these  properties.  I  hus,  the  interface  can  become  quite  extensive  without 
requiring  much  additional  work  in  this  regard.  For  example,  the  icon  juid  menu  styles  both 
show  a  user's  terminal  loc.ition.  but  they  embed  this  in  different  styles,  one  in  a  display  of 
information  about  a  single  user,  and  the  other  in  a  table  of  information  about  all  the  users. 


However,  once  the  parser  for  the  location  property  lias  been  created,  botli  presentation 
styles  immediately  offer  the  user  the  ability  to  edit  this  Held. 

6.3  Icoii-Slylc  Interface  Implementation 

This  section  and  the  following  two  describe  the  implementation  of  the  interfaces  just 
described,  building  on  PSIbtse.  The  icon-style  interface  implementation  consists  of  five 
major  parts:  presentation  style  descriptions,  opcn/close  mechanism,  move  recognition, 
recognizers  for  direct  editing,  and  simple  use  of  various  PS  Base  components. 

Presentation  Style  Descriptions.  In  general,  tlic  icon-style  interface  uses  a  graphical 
presentation  style  to  dedne  the  icons,  and  template  and  sequence  presentation  styles  to 
deluic  the  opened  presentations.  Examples  of  these  styles'  specifications  will  be  given 
below. 

The  icon  style  descriptions  arc  simple,  though  somewhat  verbose  (as  each  line,  circle, 
rectangle,  etc.,  must  be  specified  by  listing  its  properties).  These  descriptions  are  easily 
generated,  though  one  would  expcc'  a  full-scale  presentation  system  base  to  provide  more 
tools  for  creating  icons  by  editing  pictures.  (Whether  the  pictures  are  constructed  from 
lines,  circles,  etc.,  as  here,  or  from  bitmap,  or  a  combination,  is  an  independent  issue.  The 
non-bitmap  approach  used  here  wtis  chosen  because  it  used  existing  PS  Base  facilities.) 

The  presentation  style  description  for  the  document  icon  is  .shown  below: 


( clef -graph  i  cs -presen  ta  I  i  on-styl  e  DOCUMENT-ICON  TILE  nil 

nil  nil 

((nil 

(LINE-PRESENTATION  ;  Top 

:xl  ( re i a t i ve- to-paren t-x  0) 

;yl  ( rel ati ve-to-parent-y  0) 

:x2  ( re  1  at i ve- to-parent-x  16) 

:y2  ( rel at i ve- to-parent-y  0))) 

(nil 

(LINE-PRESENTATION  ;  Left 

:xl  ( rel at i ve-to-parent-x  0) 

:yl  ( rel ati ve-to-parent-y  0) 

:x2  ( rel at  i  ve-to-parent-x  0) 

:y2  ( re  1  at i ve-to-parent-y  30))) 

((:PATHNAME  : STRING-FOR-EDITOR) 

(TEXT-PRESENTATION 

:x  ( rel ati ve-to-parent-x  2) 

;y  ( rel at i ve- to-parent-y  9) 

;font  'fonts:hl6 
:mouse-trackable-p  ':no-track 
:string  (substring-or-null-string 

(send  presented-domain-object  ' : componen t-wal k 
' ( : pathname  ;string-for-editor)) 

0  4))) 

((:PATHNAME  : STRING-FOR-EDITOR) 

(TEXT-PRESENTATION 

:x  ( relative-to-parent-x  2) 

:y  O'ol ati ve-to-parent-y  19) 

: f  on  t  ' fon ts  ;  h  1 6 
:mouse-trackable-p  ':no-track 
;string  (substring-or-null-string 

(send  presented-domain-object  ’ : component-wal k 
'(:pathname  :string-for-editor) ) 

4  8)))) 

nil) 

Just  as  with  the  example  shown  in  section  5.4,  the  first  two  lines  of  this  style  description 
specify  the  name,  document-icon,  the  application  data  base  cUiss  to  which  it  applies,  yi/e,  and 
flags  specifying  here  that  it  is  not  the  default  style  for  files,  nor  is  it  an  active  presentation. 
The  first  presentation  description  in  the  following  list  specifics  the  line  across  the  top  of  the 
icon.  1  he  nil  that  starts  the  specification  indicates  that  this  line  alone  docs  not  present 
anything.  I  he  description  for  the  line  down  the  left  side  of  the  icon  is  similar.  ;is  arc  the  five 
line  descriptions  that  have  been  elided. 

The  style  description  ends  with  entries  for  the  two  lines  of  text  presenting  the  file  name. 


Hach  starts  witli  ;i  spccitlctilioii  of  the  prcscntccl  (ioiiiaiii  object.  (:  piUhniime 
:strinp,-forcdi(or).  I  liis  ineaits  th;it  the  text  is  contpiiteci  iruin  tlie  .s7/7>;^'-/b/-ir///()/- properly 
ol'the  ille's  pathname.  (A  pathname  has  several  siring  properties,  speeiijing  JilTerent  \\a>s 
of  writing  the  palhntime.)  I'he  strings  for  ihc  two  lexl  presentations  are  eompnled  by  I'orms 
that  extract  the  (list  ('oiir  letters  for  the  first  line,  and  the  secixtd  four  lor  the  second  line. 

The  text  presentation  entries  also  specify  mouse- 1 rue kablc'i)  properties.  A  :no-!ruck  value 
informs  the  mouse-tracking  mechanism  that  these  text  presentations  should  not  be  mouse- 
sensitive.  fhe  intent  of  the  style  is  that  an  icon  be  an  atomic  unit,  and  therefore  no  smaller 
ptirl  of  it  should  be  mouse-sensitive.  By  default  these  ivrcsentations  would  be  mouse- 
sensitive.  since  they  present  something.  The  lines,  on  the  other  hand,  would  not  be  mouse- 
sensitive  by  default. 

fhe  following  are  represetitative  of  style  descriptions  for  opened  presenuttions.  using 
temphite  and  sequence  presentation  styles.  I  here  arc  three  primary  styles  here;  ;i  template 
stvlc  for  the  directory  label  and  disk  usage  line,  a  sequence  style  for  the  row  of  document 
icons,  and  a  template  style  that  combines  the  label  and  row  styles. 

I'he  following  is  the  template  for  the  directory  header.  This  styic  is  also  used  by  the  other 
directory  styles,  those  used  in  the  other  two  interfaces. 

(def-template-preseiitat  ion-style  TOPS20-DIftFCTORY-llfADER 

DIRECTORY  nil 

({:se1t  tops20-directory-nanie  f  onts  ;  cp  t  f  on  tb ) 

ti  It 

( : d i sk-space-used  active-text) 

"//" 

{ : free- disk-space  active-text)) 

: hor i zon  ta 1  - 1 ayou t 
nil) 

Two  other  styles  are  referred  tc)  by  this  template.  T  he  lopslO-direc lory- name  style  simply 
presents  the  directory's  host  and  name  in  a  text  template  of  cok)n  and  brackets,  e.g.. 
"(V,:  <NSR>".  I  he  active-text  style  is  a  simple  gra|)hical  presentation  style  that  defines  a 
text  presentation  whose  string  is  the  same  as  that  it  jmesents.  ;ind  which  is  speciUcd  ms  being 
active,  updated  every  minute.  Unlike  most  graphical  presentation  styles,  it  only  spccillcs 


one  presetitation,  the  Ic.xl  presentation.  The  reason  for  lv>>  ii  is  simply  to  specify  its 
active  nature. 

Hie  following  is  the  presentation  style  description  for  the  row  of  document  icons  in  the 
directory  display: 

(def-sequence-presen tat  ion-style 

ICON -DIRECTORY- FILE -GROUP-STYLE 
{LIST-PROPERTY  DIRECTORY  :EILES  FILE) 
nil  t  999999 

nil  nil  nil 
document-icon 
:horizontal-l ay out) 

The  third  line  of  this  description,  (lisi-properiy ...).  specifies  the  property  of  the  directory 
being  presented,  namely,  the  files  property,  and  the  kind  of  objects  in  the  list,  namely,  file 
instances,  fhe  fourth  line  specifics  that  this  is  not  the  default  style  for  such  properties,  and 
that,  while  it  is  an  active  presentation,  it  should  not  (in  effect)  be  periodically  updated  --  it 
will  instead  be  updated  automatically  v/henever  the  directory  instance  in  the  application 
data  ba.se  is  changed. 

This  seciuence  luis  no  prefix,  infix,  or  suffix  presentations  (fifth  line).  The  style  used  to 
|)rcsent  the  elements  of  the  files  list  is  document- icon.  7'hc  document  icons  vviU  be 
positioned  in  a  horizontal  row. 

Finally,  the  following  is  the  template  style  description  that  composes  the  above  two  .styles 
into  the  overall  opened-dircctory  style: 

( def- tempi  ate- presentation-style 

TOPS20-DIRECTORY-ICON-LISTING-STYLE  DIRECTORY  nil 
((:self  tops20-directory-header) 

II  II 

( :files  icon-directory -file-group -style)) 

: ve  rt ical - 1 ayout 
: border-box ) 

The  third  line  of  this  template  specifies  that  the  directory  {self)  will  be  presented  both  by 
the  whole  composite  and  by  the  header  line.  The  null  string  in  the  fourth  line  effectively 
produces  a  blank  line  separating  the  header  from  the  diX'umcnt  row.  And.  as  mentioned 
previously,  the  files  property  of  ttic  directory,  a  list  of  files,  will  be  presented  in  the  style 


which  lilies  llicm  up  ;is  a  row'  of  clcxunicnl  icons,  i  lie  header,  blank  line,  and  doeiiinent  row' 
arc  laid  out  vertically,  and  a  bonier  bo.v  is  placed  around  the  entire  directory  presentation. 

Opening;,  Closinj;.  The  PSRase  mechanism  for  opening  and  closing  presentations  is 
driven  by  a  set  ofspecillcations  linking  domain  object  chesses  and  the  presentation  styles  for 
their  openctl  and  closed  presentations,  fhese  arc  easily  provided;  the  following  is  one  of 
these  speeillcations  (there  arc  four  others,  all  similar); 

(def-open-close-p re  sen  tat  ion-style  message -open-close 
message 

message-summary 
full -message 
fonts :  cptfont) 

.Move  Recognition.  Chapter  five  de.scribed  the  general  move  recognition  mechanism 
provided  by  PSRase.  fo  use  this  mechanism,  the  interface  builder  must  provide  the  move 
recognition  rules  and  some  small  semantic  recognizers  to  handle  the  recognition,  once  the 
general  organizational  recognizer  has  determined  that  it  applies.  The  following  specifics  the 
move  recognition  rule  used  for  recognizing  movement  of  a  document  icon  to  a  directory 
(either  a  folder  icon  or  an  opened  directory  display)  as  a  command  to  move  the  file  to  that 
directory  (there  are  four  other  similar  rules  specified  for  the  interface): 

(def-move- recognition- rule  move -document- to- di rectory 
(loverlap  (file  ( document- icon) ) 

(directory  (folder-icon 

tops20-directory-icon-l i sting) ) ) 
:rocognize-file-di rectory-movement ) 

The  semantic  recognizers  for  move  recognition  arc  all  very  similar.  The  following  is  a 
sample: 

(defmethod  (PRE.SENTATION  :  RECOGNIZE-MAIL-FILE-MOVEMENT) 
(out-box-presentation  edit-history -entry) 

(let*  ({file  (send  self  resol ve-presented-doma i n-object 
/V’typep  ’file)) 

( command -appl i cat  ion 

(make -command- appl i cat  ion 

( in te rn -command  'send-file-as- mail-1) 

(list  file)))) 

(send  command-application  ’:execute) 

(send  self  ' ;move-next-to-presenlation 

out-box-presentation  edithistory-entry  ’iright))) 


This  recogni/or  is  invoked  by  sending  a  rccognize-mail-file-movemeni  message  to  the 
presentation  being  moved,  the  document  icon.  It  is  given  the  out-box  icon  ;is  one  of  its 
arguments.  The  first  binding  form  in  the  lei*  resolves  the  presented  domain  object  to  a  file 
instance.  The  second  binding  Torm  creates  the  command  application,  specifying  the 
send- file-as- mail-!  command  and  an  argument  list  with  the  file  as  the  single  argument. 

The  body  of  the  let*  executes  the  command  application  (the  general  PSlhise  command 
execution  presenter  will  take  care  of  the  highlighting  automatically)  and  ends  by  moving  the 
document  icoti  to  a  standard  position  to  the  right  of  the  out-box. 

The  other  move  recognizers  are  about  this  simple.  Unfortunately,  some  need  to  specify 
highlighting  themselves  because  of  inadequacies  in  the  general  command  execution 
presenter.  (Specifically,  the  presenter  looks  for  presentations  of  the  command  or  tire 
command  application.  However,  moving  a  document  to  a  printer  does  not  involve  a 
command  presentation  --  the  printer  icon  presents  a  printer,  not  a  command.  The  out-box, 
on  the  other  hand,  presents  the  mail  command.  Perhaps  the  command  execution  presenter 
could  be  improved  to  handle  such  cases.  In  any  case,  the  highlighting  is  a  simple  matter  to 
specify.) 

6.4  Menu-Style  Interface  Implernciri  ttion 

The  implementation  of  the  menu-style  interface  consists  primarily  of  presenuttion  style 
descriptions.  For  example,  the  host  information  at  the  lop  of  the  screen  is  produced  by  tlte 
following  template  style: 

( def- tempi ate-presentat ion-styl e  HOST-INFO  HOST  nil 
("Host  " 

( : n  ame  nil) 

"  Time:  " 

(:cur rent-time  digital -clock-no-border) 

tt  ,  ft 

(: load-averages  host- info- load- aver ages) 

tt  ,  It 

( : number-of- jobs  nil) 

"  jobs.") 

: hor i zontal - 1 ayout  :border-box) 


[his  style  is  similar  to  the  other  template  styles  discussed.  One  distinguishing  feature 
here  is  the  prcsenuition  style  specified  for  the  name  and  number  of  jobs  properties;  nil 
indicates  that  the  data  b;ise  network  should  be  searched  for  the  best  applicable  default  style. 
The  two  other  sub-styles  named  are  straightforward  templates. 

Implementing  displays  with  associated  menus  has  two  parts:  specifying  the  relevant 
command  set  in  the  apidication  data  base  and  defining  the  presentation  styles.  The 
directory  presentation  will  be  used  here  as  an  example. 

The  directory  presentation  and  menu  combination  is  a  template-style  composite 
presentation,  and  as  a  whole  it  presents  the  directory.  It  has  two  sub-prcscnUitions,  the 
menu  and  the  directory  display.  These  must,  by  the  nature  of  PSBase  template  presenuuion 
styles,  present  properties  of  the  directory  (or  die  directory  itself  again  --  the  directory 
display  falls  into  the  latter  category.)  Thus,  the  interface  builder  must  be  sure  that  a 
command  set  is  defined,  consisting  of  the  relevant  commands  (present  file,  delete  file,  etc.), 
and  that  this  command  set  serves  as  the  value  of  some  property  of  the  directory  to  be 
presented.  Since  all  directories  will  share  the  same  command  set,  this  is  a  property  of  the 
entire  class,  inherited  by  each  directory  instance. 

This  is  implemented  in  the  current  PSBtise  data  base  mechanism  by  defining  a  method 
for  directory.  (All  properties  are  accessed  by  the  message  passing.  Some  properties  are 
defined  by  the  contents  of  slots  in  the  instances;  but  the  Lisp  machine  message-passing 
system  automatically  creates  methods  to  retrieve  these  as  well.  Thus,  the  property  accessing 
is  uniform.)  This  mctliod  is  shown  below: 

(de.'method  (DIRECTORY  :  F ILE-COMMANO-SET)  () 

*sliOrt-f  i  1  e-command-set* ) 

This  defines  the  file  command  set  property  for  directories.  It  returns  the  command  set 
instance  in  the  data  b:tse  network  that  the  variable  *short-file-command-sel*  is  bound  to. 
That  variable  and  the  command  set  instance  in  turn  are  created  from  the  following 
specification: 


179 


(defvar  ‘SHORT- F ILE -COMMAND-SET* 

(make-command-set-f  rom-spec 
'  ( present-f i 1 e 
delete-f ile 
dover-pr  in  t-f i le 
1  ine-print-f ile))) 

This  specification  dcllncs  a  coininaiul  set  instance  by  simply  listing  llic  names  of  the 
commands  to  be  incitided.  Ihese  commands  are  defined  individually  elsewhere.  (They 
may  be  included  in  several  different  command  sets.  The  PSna.se  command  description 
mechanism  interns  command  instances  in  the  data  btise  network  btised  on  their  L.isp 
function  specifications.)  For  example,  the  command  description  for  the  present-file 
command  is  written  as  follows: 

(def -command  PRESENT-FILE 

:arglist  ((parameter  :select  : domain-object 

:domain-object-type  file 
;presentation-type  t) 

(parameter  :select  ;position))) 

The  interface  builder  must  also  write  the  funelions  for  the  presentation  commands  that 
appear  in  these  menus.  The  definition  of  the  present-file  function  is  tis  follows: 

(defun  PRESENT-FILE  (file-instance  position) 

(send  file-instance  ' :make-contents) 

(present  f  i  le- instance 

(position-x  position)  (position-y  position) 
n  i  1 

'text-file-contents)) 

This  function  (like  the  open  mechanism  discussed  in  chapter  five)  first  ensures  that  the 
file  instance  includes  the  current  contents  (the  text  of  the  file).  The  file  is  then  presented: 
the  present  function  is  a  general  one  that  takes  as  arguments  the  application  data  biusc  object 
(the  file  instance)  to  be  presented,  the  position  for  the  presentation,  the  default  foiit  (none 
specified  here),  and  the  name  of  the  presentation  style  to  use  (text-fle-contents).  Since 
these  present-...  functions  all  tend  to  have  this  stinic  structure,  there  is  potential  for 
converting  this  task  of  writing  functions  to  simply  describing  the  action,  as  is  done  with 
open/close  mechanism. 

Some  of  the  presentation  styles  were  shared  with  the  icon-style  interface.  (In  the  icon- 
style  interface  these  were  till  used  tis  opened  presentations.)  riu'se  shared  styles  are.  first. 


Ihc  presentation  of  files  showing  pathname,  destination,  and  text  contents;  second,  the 
presentation  of  the  mail  file  by  showing  message  summary  lines;  and  third,  the  presentation 
of  the  text  of  messages. 

1  he  recognition  of  direct  edits  is  exactly  the  sttme  as  in  the  icon-style  interface.  In  fact,  no 
additional  work  w;\s  done  at  all  here,  since  all  die  parsers  for  the  properties  had  already 
been  defined. 

6.5  Annotation-Style  Interface  Implementation 

The  annotation-style  interface  uses  the  same  presentation  styles  tis  the  menu-style 
interface,  differing  only  in  the  choice  of  the  command  sets  and  top  level  presentiition  style 
for  the  directory.  (In  the  annotation-style  interface  the  top-level  directory  presentation  is 
just  the  directory  listing,  without  the  associated  menu.) 

The  command  execution  presenter  provides  the  facility  whereoy  the  a.nnotation  verbs  are 
changed  to  past  tense  (in  additiiin  to  providing  the  command  highlighting).  The  annotation 
recognizer  only  needs  to  record  the  presentation  style  (namely,  the  annotation  presentation 
style)  in  the  annotation  presentation  instance.  The  command  execution  presenter  checks 
the  command  presentation  (which  it  hits  been  highlighting)  for  being  of  that  style;  if  so,  the 
verb  is  changed  to  past  tense. 

The  bulk  of  the  effort  was  devoted  to  writing  the  annotation  recognizer.  Unlike  the  other 
mechanisms  di.scusscd  in  these  interface  implementations,  the  annotation  recognizer  is  fairly 
large  and  is  both  style-specific  and  domain-specific.  It  did  not  prove  very  difficult  to 
modify  at  various  times,  as  parts  of  the  structure  seem  almost  descriptive.  However,  a  better 
approach  for  future  development  would  be  to  abstract  a  general  PSBasc  mechanism  driven 
by  a  set  of  interface-specific  annotation  dcxriptions.  This  seems  to  be  plausible,  judging 
from  the  final  structure  of  the  programs. 

Recognition  of  the  annotations  works  by  matching  structural  patterns  against  tlie 
presentation  data  base  structure  and  checking  presented  domain  objects  of  eligible 


prcsciitnlions.  For  example,  consider  the  case  of  an  arrow  conncclint;  the  text  "delete"  with 
a  presentation  of  a  file.  The  recognizer  starts  by  checking  that  the  text  presentation  is  a 
command  verb.  Its  job  is  now  to  verify  that  this  is  indeed  a  presentation  of  a  delete 
command  application  and  to  determine  its  arguments. 

The  organizational  recognizer  collects  lines  and  arrows  attached  to  the  text  prc.sentation 
and  collects  the  presentations  at  the  other  ends;  here,  only  one  arrow  is  collected. 

The  semantic  recognizer  part  checks  that  the  presentation  at  the  other  end  of  the  arrow 
matches  (by  reference  resolution  if  necessary)  something  that  can  be  deleted.  In  this  case, 
the  domain  object  is  a  file,  ;uid  the  command  application  can  be  created,  with  the  file  as  its 
single  argument. 

Even  though  the  iinnotation  recognizer  is  a  fairly  large  and  complex,  hand-written 
program,  compared  with  the  other  interface-specific  parts  of  the  project  the  annotation 
recognizer  still  benefits  from  PSBase  support.  Its  recognition  task  is  simplified  by  having  a 
structured  presentation  data  base:  it  does  not  have  to  do  any  work  to  find  arrows  and  lines 
connected  to  the  verb  text.  And  because  the  presentation  data  base  records  presented 
domain  objects  for  the  rich  structure  created  by  the  directory  presenter,  recognition  is  an 
incremental  task  -  only  the  annotations  to  the  directory  need  be  recognized,  and  the 
recognizer  can  easily  check  that  presentations  at  the  ends  of  delete  arrows  present  files,  or 
those  at  tlic  end  of  change  lines  present  properties  that  may  be  changed,  for  instance. 

These  checks  are  aided  too  by  the  PSBase  reference  resolution  mechanism:  whether  the 
presentation  at  the  end  of  the  change  arrow  presents  a  date,  a  time-and-date,  a  property 
whose  value  is  one  of  those,  etc.,  is  immaterial  -  when  the  recognizer  checks  a  change- 
reference-date  annotation,  it  need  only  ask  the  resolution  mechanism  to  check  for  a  date 
instance. 

Part  of  the  previous  two  points,  and  a  more  general  benefit  as  well,  is  the  fact  that  the 
application  data  base  is  constructed  from  a  uniform  data  base  mechanism. 


And  finally,  the  larger,  interactive  nature  of  tlie  interface  benefits  from  the  general 
PSfiase  recognition  dependency  and  retraction  mechanism.  7'he  annotation  recogtii/er  docs 
not  need  to  consider  clianges  in  the  annotation  siaicturc  IVom  a  previously  rccogni/ed  state 

-  any  such  changes  cause  the  previous  recognition  to  be  retracted  automatically.  The 
rccogni/cr  only  needs  to  consider  the  recognition  from  an  unrecognized  stale  and  to  inform 
the  dependency  mechanism  of  the  presentations  on  which  the  recognition  depends  and  how 
to  retract  the  recognition  it  specifics. 

6.6  Other  Style  Po.ssibilities 

Combinations.  Ihcsc  interfaces  do  not  have  to  be  (and  were  not  in  this  project) 
constructed  separately.  The  interface  builder  can  develop  them  together,  combining  them 
at  various  times,  experimenting  with  combinations  of  presentation  styles  in  order  to  develop 
a  desired  overall  style,  and  so  on.  One  command  that  PSBase  provides  in  this  regard  is  the 
change  presentation  i/v/c  command.  I  he  command  is  given  a  presentation  as  its  argument. 
The  set  of  a!!  p.''cscnta.(!0!i  styles  applicable  to  the  presentation's  presented  domain  object  is 
collected.  The  user  selects  one  of  the  applicable  styles  from  a  menu,  and  the  presentation  is 
replaced  with  a  new  one,  of  the  same  domain  object,  in  the  selected  style.  Thus,  the  builder 
or  user  can  be  offered  control  over  the  way  the  objects  in  the  application  data  base  are 
presented. 

I^lanniiig.  In  the  interfaces  developed  here,  only  the  annotation-style  included  planning 

-  the  .separation  of  accutmilation  and  recognition  of  commands  from  their  execution.  The 
other  styles  appear  to  inherently  be  more  of  a  direct  manipulation  style  of  interface. 
However,  one  can  imagine  developing  extensions  of  those  styles,  adding  features  of  the 
annotation  style  to  add  planning. 

The  user  could  create  arrows  between  presentations  in  the  icon-style  interface  to  present  a 
planned  move  --  and  therefore  a  planned  command  using  the  move  recognizer.  For 
instance,  the  user  could  draw  an  arrow  from  a  document  icon  to  a  printer  icon.  This  could 
be  recognized  as  a  plan  to  print  that  file.  1  he  user  could  see  this  recognition  documented. 


;is  in  the  annotation-style  interface,  anti  accunuilatc  a  set  of  move-arrow  plans  before  giving 
the  command  to  execute  them. 

Similarly,  some  commands  could  be  planned  by  drawing  arrows  in  the  menu-style 
interface,  an  arrow  from  the  delete  file  menu  item  to  a  file  presentation,  for  example.  Some 
menu  commands  might  require  more  than  one  input,  which  would  require  a  somewhat 
more  complicated  visual  style  to  distinguish  and  group  the  different  inputs  to  a  planned 
command  application. 

6.7  Summary 

This  chapter  has  described  the  construction  of  a  user  interface  on  top  of  the  PSBrtse 
system  described  in  chapter  five.  Three  alternative  styles  were  implemcittcd.  The 
implementation  comprised  two  major  phases: 

The  first  phase  was  style-independent,  primarily  the  creation  of  the  application  data  base 
(iind  the  background  process  that  periodically  updates  the  application  data  base).  Other 
style-independent  work  is  the  writing  of  the  simple  dircct-cdit  recognizers. 

The  second  phase  (for  the  icon-style  and  menu-style  interfaces,  at  least)  primarily 
consisted  in  using  the  PSBasc-provided  tools  for  defining  and  describing  presentation  styles, 
commands,  command  sets,  move  recognition  rules,  and  prc.senLation  styles  for  opened  and 
closed  domain  objects.  These  definitions  have  been  illustrated  in  this  chapter,  and  each  is 
small  and  am  be  quickly  and  independently  written.  The  examples  given  in  this  chapter  are 
representative;  the  others  are  of  about  the  sitme  difficulty  :ind  size,  dhe  an  notation -style 
interface  required  significant  additional  work  in  writing  its  recognizer.  An  improved 
PSI3ase  would  reduce  this  work  to  the  scale  of  the  other  styles:  the  builder  would  simply 
write  a  few  simple  descriptions  of  the  annotation  style. 

In  other  words,  once  the  style-independent  work  has  bcc/i  completed,  implementing  a 
particular  style  is  generally  a  matter  of  writing  a  relatively  few  small  pieces  using  PSBase 
tools  and  choosing  some  standard  PSBiise  components.  This  project  has  demonstrated  tliat 
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even  the  small  number  of  features  provided  by  PSIiase.  a  prototype  presentation  system 
bjise.  covers  a  substantial  amount  of  ground,  enhanced  by  the  ability  to  combine 
mechanisms  in  jin  independent  manner. 

Some  rough  statistics  on  the  project  reported  here  may  help  to  support  the  claitns  about 
the  ease  and  speed  with  which  interfaces  can  be  built  on  top  of  a  presentation  system  base. 
(  Ihis  discussion  primarily  covers  just  the  icon-style  and  menu-style  interfaces,  since  the 
annotation-style  interface  was  developed  together  with  PSBase  at  an  earlier  stage.)  Of  the 
roughly  thirty  days  spent  on  the  project,  more  than  half  were  devoted  to  further  work  on 
PSBase  itself  About  five  or  six  days  were  devoted  to  creating  the  application  data  biise,  the 
background  management  process,  and  the  other  common  parts  of  the  implementation.  The 
background  process  took  most  of  the  time,  more  than  anticipated,  partly  due  to  the 
problems  of  getting  information  from  a  distant  host  via  communication  network 
connections.  (A  few  days  involved  determining  the  network  scheme  best  suited  for  tliis 
experiment.) 

About  seven  days  were  required  to  build  the  icon-style  and  menu-style  interfaces  (and  the 
parts  of  the  annotation-style  interface  that  had  not  yet  been  completed  -  the  parts  other 
than  the  annotation  recognizer).  This  includes  time  spent  at  the  end  changing  styles  to 
experiment  with  the  look  of  things. 

Tlius.  six  days  were  required  for  style-independent  work  and  seven  days  for  the  style- 
specific  work  on  the  three  different  style  implementations.  An  interesting  note  is  that,  while 
many  interfice  builders  will  be  constructing  only  one  interface,  some  builders  will  want  to 
experiment  with  different  styles,  this  project  illustrates  how  the  experimentation  process  is 
helped  too:  the  stylc-indcpcndcnt  work,  nearly  half  the  effort  here,  is  done  just  once. 

Another  statistic  is  the  number  of  presentation  styles.  At  the  project’s  end  there  were 
about  80  styles  defined.  Several  of  the  PSBase  tools  evolved  during  the  project,  and  this 
number  would  be  less  if  the  prcscmalion  styles  were  defined  from  scratch  now  -  the 
number  might  be  closer  to  50  or  60.  This  chapter  and  chapter  five  have  shown  seven  of 
these.  I  hcsc  numbers,  in  any  case,  arc  not  very  large,  and  the  definitions  arc  simplified  by 
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the  fact  that  they  do  not  have  complex  iiueractions.  { I  hcy  have  few  iiueraclions,  in  Tact 
-  merely  the  static  inclusion  of  one  style  within  another.) 

Similarly,  though  only  one  move  recognition  rule  and  one  open/closc  rule  have  been 
included  here  (and  one  of  each  in  the  previous  chapter),  there  are  only  tiboul  five  others  in 
ctich  ctitegory.  The  tot;il  in  both  categories  is  no  nurre  than  ;i  page  ofdelinitions. 

The  characteristics  ;ind  statistics  discussed  lend  credence  to  claims  that  a  presentation 
system  base  greatly  etises  and  speeds  the  development  of  a  user  ititerface.  Ihese  arc  not 
flawless  arguments,  unfortunately.  First,  this  has  only  been  one  project.  It  benefits  in 
generality  by  including  different  styles,  but  there  arc  a  few  categories  that  have  not  been 
included;  one  such  is  command  completion  [■rops20  80]  (Zmacs  84]  (and  see  section  4.2, 
page  78).  Second,  the  project  is  a  demonstration,  not  a  user  interface  that  will  really  be 
used.  It  lacks  many  features  Unit  would  be  required.  The  intent  was  to  pick  a  representative 
sample  of  these  features  and  to  attemi)t  to  at  least  mimic  styles  and  characteristics  that  are 
used  in  good-quality  user  interfaces.  However,  one  cannot  s;ty  that  a  good-quality, 
production  user  interface  has  yet  been  constructed  on  a  presentation  system  base.  More 
work  needs  to  be  done,  to  build  more  substantial  presentation  system  bases  and  to  discover 
just  what  benefits  they  can  provide. 


Chapter  Seven 
Areas  for  lAirther  Research 


Ihis  icpoit  (liscLisscs  picsentation  based  user  imerfates  in  iwo  niaji)r  phases:  llrsl, 
tliscnssion  of  the  piesenlalion  system  model  and  its  use  in  deseiihing  existing  user 
interfaees;  and  second,  discussion  of  PSBase,  the  prototype  presentation  system  base  for 
building  user  interfaees.  haclt  area  can  be  furtlier  studied;  both  the  moilel  and  PSBase  liavc 
tlie  character  ol'a  IVamework  and  need  to  be  lleshed  out 


riic  prcsenltition  system  model  could  be  developed  further,  its  structure  rellned.  More 
general  p;ir;imeters  could  be  identified,  kinds  of  presenter  and  recogni/er  control,  for 
insltincc.  or  general  ambiguities  in  recognizer  action. 


!  here  ts  currently  htiiiiati  ftetors  research  into  whitt  user  interfaces  should  do  for 
particidtir  user  groups,  for  insfitice,  what  properties  they  should  have,  what  the  structure  of 
dialogs  should  be,  and  what  error  messages  should  say.  However,  there  needs  to  be  more 
work  done  from  the  opposite  end,  determining  what  user  interfices  can  do  --  what  the  range 
of  possible  styles  is.  In  terms  of  the  dellnition  of  styles  as  patterns  of  presentation  system 
pammeters.  the  possible  fundamental  structures  for  these  patterns  shouki  be  determined, 
thus  tiefining  brotitl  classes  of  styles. 


7.1  r.SBaso  Limilalion.s 

IkSBase  has  several  (imitations.  (’SBtisc  is  ;i  prototype,  not  a  full-.scale  prodiictitrn  system. 
Several  parts  of  its  implementation  are  patchy  or  somewhat  inconsistent,  resulting  from  the 
evolution  of  its  tlesign  and  the  |iressure  of  time.  It  provides  examples  of  various  features 
ih.it  a  presentation  svsiem  sluruld  have,  enough  in  fict  to  buiki  the  interfice  tliscussed  in  the 
next  chapter.  However,  more  features  in  c.ich  category  need  to  be  |vrovided.  tlie  e\i'^ting 
mechanisms  need  to  be  improvetl.  especially  in  older  to  better  match  the  structure  of  the 


presentation  system  model,  and  various  mechanisms  could  benefit  rre)m  being  unined. 

More  I'caturcs  Offered.  Although  this  chapter  has  iu>t  fully  enumerated  all  the  features 
offered  in  each  major  category,  most  of  the  features  have  been  illuslrated.  The  following 
lists  w-hat  w'ould  be  required  for  a  full-scale  presentation  system  base: 

*  More  kinds  of  presentations,  presentation  relations 

*  More  presentation  editor  functions 

*  More  curve  recognizers 

*  More  command  argument  parameter  types 

*  More  (and  cleverer)  organizational  presenters 

*  More  presenters 

*  More  recognizers,  recognizer  drivers 

Better  Mechanisms.  In  addition  to  providing  more  each  kind  of  feature  or  mechanism, 
those  that  have  been  provided  coidd  be  improved,  by  being  made  more  general,  more 
efficient,  or  more  intelligent.  The  following  lists  the  most  important  improvements  needed; 
tlie  first  three  arc  important  in  a  general  sense,  in  that  they  arc  requirements  that  PSBiise 
match  the  structure  of  the  model  more  closely: 

*  Allow  specification  of  semantic  presenter  style  separate  from  domain  collector, 
so  it  can  be  shared  between  styles,  as  organizational  collector  is 

*  Allow  identification  of  parts  of  presentation  data  base  as  PPS  units 

*  Allow  recognizer  invocation  to  depend  on  presentation  context,  or  vary  between 
PPS  units 

*  Improve  the  data  base  mechanism:  richer  structure,  knowledge  representation 
language,  perhaps:  better  matching  procedures 

*  Have  move  recognizers  driven  more  from  descriptions,  so  interface  builder  docs 
not  need  to  write  the  semantie  recognizers 


l  ilificd  Mechanisms.  I'vvo  inajor  kiiuls  of  imilkatioii  needs  Id  be  achieved  in  I’SBase 
nieelianisms.  F  irsl  is  tlie  invocalion  ofeonliiuial  and  general  leeogni/er.s.  I  lie  rlislinelion 
betw  een  the  two  kiiuls  of  reeogni/ers  does  not  seem  to  be  an  inherent  one,  noi  is  it  a  sliarp 
distinction  even  in  the  enrrent  implement.ition.  I’erhairs  there  could  be  a  single  leeogni/er 
invocation  mechanism. 

Second,  the  various  presentation  style  (.ieseriptions  should  be  uniried  into  a  single 
langiKige  for  describing  presentation  styles.  I  be  three  kinds  tif  de.seriptions  shown  in 
section  5.4.  for  denning  graishical,  set|iiencc.  and  template  presentation  stales,  are  very 
similar.  Making  a  single  description  language  that  merges  the  capabilities  of  the.se  three 
kinds  of  denning  forms  should  not  be  dirficult. 

Beyond  that,  however,  the  description  of  presentation  style  might  be  interpreted  by  more 
than  just  ;i  presenter.  I’erhaps  it  could  be  interpreted  by  a  rccogni/er  as  well.  I  bis  would 
then  ensure  tluit  many  presenters  and  recogni/ers  wcnild  be  inverses,  allowing  the  interface 
builder  to  provide  greater  uniformitv  in  the  interface  .style,  between  the  presentation  style 
used  for  output  (constructed  by  presenters)  and  the  presentation  style  used  for  input 
(rccogni/ed  from  user  constructions). 
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